Transferring Technical debt to automated Production Systems (aPS)

© A

IS

Outline

1B. Vogel-Heuser23.05.2015

1. Domain specific constraints

2. Types of Technical Debt

3. Causes of Architectural Technical Debt in aPS

4. ATD- Parallel development –Pick&Place Unit

5. Accumulation and RecoveryModels

6. Conclusion and Outlook

Transferring Technical debt to automated Production Systems (aPS)

Univ.-Prof. Dr.-Ing. Birgit Vogel-Heuser [email protected]

Head of Chair and Director of Institute, Automation and Information systems (AIS)Faculty of Mechanical Engineering, Technische Universität München

Source: Siemens AG

Source: Bayer AG, Leverkusen

© A

IS

aPS as long living systems


Development and

Construction

OperationCommissioning

of System

20- 50 Years

10 - 15 Years

Life-Cycle

Automation hardwareand electrics / electronics

Mechanics (Context)

Software1,5 Years

Commissioning after Re-Engineering

Sensors/Actuators8 -12 Years

Automation hardware10 -13 Years

HMI1,5 Years

Microcontroller 3 - 5 Years

Chips1,5 Years

Source: B. Vogel-Heuser, J. Folmer, C. Legat: Anforderungen an die Softwareevolution in der Automatisierung des Maschinen- und Anlagenbaus. In: at –Automatisierungstechnik, 62(3), 3/2014

Technical Constraints of software for aPS


• Real-time requirements of aPS hard real-time for the used platform PLC

• Cyclic behavior of the platform (1µs – 1s)

• Classical PLC as well as Soft-PLC (PC-based) programmed in IEC 61131-3 Languages

• Increasing amount of IPC and C, C-derivatives

• Online change is mandatory

CPU (platform)

Inputs

PLC-Code Execution

Outputs

Process Data

Technical Process (context)

Technical system (context)

Sensor signals

Actuator signals

IEC 61131-3 Languages

Sequential Function Chart

Step1

Step2

Step3

.

.

.

.

.

.

Transition 1

Transition 2

Transition 3

Ladder Diagram

Var1 Var2 Var3

Var5 Var4

OUT

Instruction ListLDN Var1ANDN Var 2ANDN Var3ST OUT

Function Block Diagram

Var1Var2Var3

&

Var4Var5 &

>=1 OUT

Structured Text

OUT:=(Var1 & Var2 & Var3) OR(Var4 & Var5)

IEC 61131-3 Programming Languages• Proprietary programming languages:

Structured Text (ST), Ladder Diagram (LD), Instruction List (IL), Sequential Function Chart (SFC), Function Block Diagram (FBD)

• Upcoming: C

© A

IS

Life cycle phases for aPS


Mechanical design

Electrotechnical design

Softwaredesign Co

mpo

nent

TES

T

Mechanical assembly

Electrotechnical and Software

integration Inte

grat

ed T

EST

Manufacturing

Cabinetconstruction

Softwareimplementation

Requ

irem

ents

sp

ecifi

catio

n

Syst

em

spec

ifica

tion

Syst

em d

esig

n

Ope

ratio

n /

Mai

nten

ance

Proj

ect

com

plet

ion

Syst

em h

ando

ver

Star

tup

Com

miss

ioni

ng

Syst

em d

eliv

ery

Syst

em in

tegr

atio

n

© A

IS

Design (el.) =

Manufacturing (el.) =

Enlarged Types of Technical Debt (TD) in aPS according to the enlarged life cycle model

B. Vogel-Heuser23.05.2015 5

Requirements TD

Design TD

Test TD

Build TD

Documentation TD

Infrastructure TD

Versioning TD

Defect TD

Architectural TD

Operational & Maintenance TD

Assembly TD

Manufacturing TDCode TD

Start Up TDCommissioning TD

Enla

rged

Typ

esof

Tec

hnic

al D

ebt f

or a

PSba

sed

on (

Li e

t al.

2015

)

→ Circuit / Wiring diagram→ Terminal connection table→ Mounting of devices in

the cabinet

Source: durau.deSource: systech-gmbh.de

Effect: sporadic faults

= textual description in contract plus layout

= different architectural approaches and artifacts in disciplines

© A

IS

Causes of Architectural Technical Debt in aPS

B. Vogel-Heuser23.05.2015

Type

sof

Tec

hnic

al D

ebt (

Li e

t al.

2015

)

Requirements TD

Design TD

Code TD

Test TD

Build TD

Documentation TD

Infrastructure TD

Versioning TD

Defect TD

Architectural TD

6

Sources: Z. Li, P. Avgeriou, P. Lang: A systematic mapping study on technical debt and its management. In: The Journal of Systems and Software, pp. 293-220, 2015.A. Martini, J. Bosch, M. Chaudron: Architecture Technical Debt: Understanding causes and a qualitative model. In: Conference on Software Engineering and Advanced Applications, pp. 85-92, 2014

Business evolution

Time pressure

Split of budget

Always heavy penalties for late delivery on-site, acceptance as well as plant availability

• Lack of cross-discipline responsibilities, different teams for each discipline

• Lack of budget for software maintenance

• New application domain, e.g. food & beverage

• Varying standards in different countries e.g. CSA, UL, VDI/VDE

• Different environmental conditions e.g. humidity, temperature, etc.

Reuse of Legacy and third party

code

Design and architecture

documentation

Parallel development

Business factors

Technology evolution

Effects uncertainty

Non-completed refactoring

Human factors

Causes of Architecture Technical Debt (ATD) (Martini et al. 2014)

© A

IS

Causes and effects of ATD in aPS – selected examples

B. Vogel-Heuser23.05.2015 7

See application exampleParallel development

Design and architecture

documentation

• Only very rough textual specification given in contract

• Lack of clear specification, misunderstanding -> inappropriate interfaces or functionality

Technology evolution • Change of PLC-, drives or HMI-platform, heterogen. fieldbus • Interoperability problems

Reuse of Legacy and third party

code/components

• Outsourcing hardware and/or software development due to lack of development capacity/resources

• Poor quality (tools), violation of company standards, further development usage impossible

Effects uncertainty • Changes have unforeseen effects on other discipline

• Change of motor, requires different frequency converter

Non-completed refactoring

• Need to maintain backward compatibility for a decade

• Hinders new architectures and structures

Human factors

• Not invented here phenomenon• Gap of knowledge between

commissioning and start-up staff and design staff

• New designed solutions on-site (costly)

• Violation of internal standards• inappropriate solutions from

design department

causes Sub-causes effects

Cau

ses

of A

rchi

tect

ure

Tech

nica

l Deb

t (AT

D) (

Mar

tini e

t al.

2014

)

© A

IS

ATD parallel development


© A

IS

Hardware change and software change: additional sensor during start-up onsite parallel development


Sorting Station to sort work pieces from beltinto slides

Mac

hine

gro

up

Dev

ice

num

ber

Dev

ice

Func

tion

Loca

tion

Dev

ice/

Sign

alty

pe

Pow

er s

uppl

y [V

]

Rem

arks

310 M1 sorting line

sort/pushWP in slide

1

Pusher pneum. valve DO

24V mand.

310 B1.1 sorting line

pusher is extended

Pusher reed switch DI

24V mand.

310 B1.2 sorting line

pusher is retracted

Pusher reed switch DI

24V mand.

320 M1 sorting line

sort/pushWP in slide

2

Pusher pneum. valve DO

24V mand.

… … … … … … … …

retractextractB1.1B1.2

FB_Error_Calcul

ErrCode

FB Interface

FunctionalityExtract Pusher

FunctionalityRetractf Pusher

FunctionalityError Code Calculation

extractretract

ANDB1.2

NOTS M1

extractretract

ANDB1.1

R M1NOTextractretract

ANDB1.1

R

B1.430,000

>=

M1NOT

retractextractB1.1B1.2B1.4

FB_Error_Calcul

ErrCode

extractretract

ANDB1.2

NOTS

B1.41,000

<=

M1

M1ErrCodeextract

retract

B1.2B1.1

B1.4

FB_Pusher

© A

IS

– Crisis-based ATD management• software tends to be unreadable and unmaintainable or lead to unpredicted behavior• refactoring is unavoidable but not planned – leading to a weak solution

– ATD accumulation and recovery during feature development• ATD grows with every modification of software or electrics not compliant with valid

explicit or implicit rules– during optimization of existing plants– during interdisciplinary development of new plants

– Events initiating ATD recovery• development of a new machine or machine generation (continuous product change)• based on a new technology • different market requirements (products), e.g. thinner or thicker particle boards • different tools, e.g., the introduction of a new engineering tool in electrical engineering

or software engineering• the change of a team leader • the limitations of a numbering system e.g. for MCL implicitly representing the variants

TD and ATD accumulation and recovery models


© A

IS

Management strategies to deal with TD and ATD can be developed in future work focusing on the plant manufacturing industry

Need for industrial case studies to gain more data and classify different ATD recovery models

Should lead to a deeper understanding of obstacles for a systematic evolution of aPS

Concepts of TD and ATD are in principle applicable to aPS Dimensions, some causes and some effects were introduced Challenges of interdisciplinary relations

Conclusion and outlook


© A

IS

• Z. Li, P. Avgeriou, P. Lang: A systematic mapping study on technical debt and its management. In: The Journal of Systems and Software, pp. 293-220, 2015.

• B. Vogel-Heuser, J. Folmer, C. Legat: Anforderungen an die Softwareevolution in der Automatisierung des Maschinen- und Anlagenbaus. In: at – Automatisierungstechnik, 62(3), 3/2014.

• E. Tom, A. Aurum, R. Vidgen: An exploration of technical debt. In: The Journal of Systems and Software, pp. 1498-1516, 2013.

• A. Martini, J. Bosch, M. Chaudron: Architecture Technical Debt: Understanding causes and a qualitative model. In: Conference on Software Engineering and Advanced Applications, pp. 85-92, 2014

Literature


Documents

Transferring Technical debt to automated Production Systems (aPS)