View
227
Download
3
Category
Preview:
Citation preview
© 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 vogel-heuser@tum.de
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
2B. Vogel-Heuser23.05.2015
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
3B. Vogel-Heuser23.05.2015
• 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
4B. Vogel-Heuser23.05.2015
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
8B. Vogel-Heuser23.05.2015
© A
IS
Hardware change and software change: additional sensor during start-up onsite parallel development
9B. Vogel-Heuser23.05.2015
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
10B. Vogel-Heuser23.05.2015
© 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
11B. Vogel-Heuser23.05.2015
© 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
12B. Vogel-Heuser23.05.2015
Recommended