EN 
DE Authors: Thomas Aicher, Huan Dong, Birgit Vogel-Heuser, Chair of Automation and Information Systems, TU Munich
Contribution – Embedded Software Engineering Congress 2017
Often, when resolving a technical problem under time pressure, a decision must be made between a less expensive, but "suboptimal" solution and a more complex, "better" solution. Engineers, technicians, and decision-makers frequently face this dilemma during the development, operation, and commissioning of an embedded system (ES). They must consider the project situation, the remaining timeframe, and costs. Technical debt (TD) refers to the deliberate decision against a better, more sensible solution. Although TD is a well-known and researched phenomenon in traditional software engineering, it has received little attention and is consequently poorly understood in the fields of embedded systems and mechatronics, such as production systems. The resulting financial losses for companies are considerable. Therefore, providing transparent criteria for making informed decisions regarding the acceptance of TD is of particular importance. Based on an extension of the TD classification from software engineering and a cross-domain case study, TD and its effects, as well as the potential for controlling TD, are discussed. To achieve the required transparency, both the short-term and long-term effects are presented and compared for embedded systems.
Introduction and Motivation
The term "technical debt" (TD) was introduced in the field of software engineering more than two decades ago [1]. TD describes the long-term negative effects that arise when a suboptimal solution is deliberately chosen in the short term instead of a more complex "optimal" solution. While TD is a well-known research topic in software engineering, it has not yet found its way into the fields of embedded systems (ES) and mechatronics, such as production systems. A common application area for ES is machinery and equipment, but also more or less complex mechatronic systems such as trains, vehicles, or construction machinery. All these mechatronic systems can be considered a composition of mechanical, electrical, and software components that are subject to various life cycle phases – development, commissioning, and maintenance (see Fig. 1, PDF) – interact [2].
In particular, commissioning, maintenance and further optimization represent additional phases in which TD can occur (Fig. 1, PDFDepending on the size and complexity of the machine and the product being manufactured, testing is conducted both in the factory and on-site. Often, an engineering feature (ES) in a machine cannot be fully tested before final commissioning. Therefore, commissioning engineers are frequently under considerable time pressure, and errors must be rectified or new solutions developed quickly on-site. Many examples of technical development (TD) can be found in this commissioning phase. The subsequent maintenance costs of such bug fixes or on-site developments, often in parallel with more systematic solutions from the design phase, exceed the initial cost savings during commissioning. These high maintenance costs result from the long life cycles (often exceeding 20 years) of machines and systems, as well as the frequent use of more than 100 machines simultaneously. The goal of cost analysis within the framework of TD is not only to consider manufacturing and commissioning costs, but also the operating costs for the customer.
For mechatronic systems [3], however, not only the software but also the disciplines of mechanics and electrical/electronic engineering must be considered. In the following, TD will still be considered from the perspective of the software discipline, but in interaction with the other disciplines. Based on the case study of a machine and plant manufacturer, the TD classification is extended and a visualization of TD for ES in this area is proposed.
Methodology and case study
In interviews with machine and plant manufacturers, we were able to gather various typical examples of technical design (TD) in electronic systems (ES). In parallel, a representative study was conducted with more than 80 companies from various ES application areas using a web-based online survey. The TD classes known from software engineering could thus be extended to include multidisciplinary and lifecycle-specific classes for ES in mechatronics. The following section presents one such TD class for the case study of a leading global machine and plant manufacturer that, among other things, integrates robots into its systems.
During the commissioning of a system, technicians discovered a reversed wiring issue within a robot (an electrical/electronic fault). Although the technicians could have corrected the wiring problem on the robot itself, they did not. Instead, they modified the software interface of the control software. This change was not documented in either the software documentation or the electrical schematic. As a result, a Technical Documentation (TD) was created in the documentation and another in the electrical engineering discipline during commissioning. Both are quite typical, as software is often easier and quicker to modify.
After several years, the robot was replaced with an identical new robot with correct wiring. However, because the software was still configured to control the incorrectly wired robot, the new robot performed unexpected (inverted) maneuvers, causing damage to the system. Part of the system had to be repaired as a result of this incident. This damage caused considerable financial losses for both the machine supplier and the operator.
Since the documentation of the robot's wiring and control software was not updated after the fault was found and the software was adjusted, three TD classes exist (see Fig. 2)., PDFFirstly, the fault occurred during commissioning of the robot, because the incorrect wiring within the robot arose during its integration into the system at the factory, but was not identified there due to a lack of testing. The error was only identified during commissioning at the construction site, and due to time constraints, the solution (bug fix) was implemented in the software.
The second technical fault (TD), code TD, arose from the modification of the software interfaces contrary to the standard interface, leading to the need to maintain different versions of this interface. The third TD is documentation fault, resulting from the lack of documentation, meaning that when the robot is replaced with a new one, there is no indication of the necessary adjustments to the incorrectly implemented interface. The resulting damage stems from these three types of TD.
Extended TD classes for ES in mechatronics and mechanical and plant engineering
The discussed TDs for ES in mechanical and plant engineering extend the classifications of software engineering [6] (see Fig. 2, PDFThe additional dimensions relate to the further phases of the life cycle of such ES, such as system integration, commissioning, and operation and maintenance. Furthermore, additional dimensions are also specified for the disciplines involved, i.e., mechanics and/or electrical/electronics [2].
Costs of TD in ES for mechanical and plant engineering (results of the online survey)
Building on various questionnaire-based studies on the maturity of software development and the engineering of electronic systems in mechanical and plant engineering [7], the most recent questionnaire (activated since July 2017) includes six questions on technical development (TD). The participating companies operate in various sectors, including automotive, medical technology, robotics, etc. Participants come from the software sector as well as from the electrical/electronic and mechanical engineering disciplines. A total of 80 completed questionnaires have been received, but only 51 could be considered so far. The remaining data received can be included after the questionnaire closes in November 2017. Some selected aspects are presented below:
TD most often causes additional and long-term costs in the area of software (see Fig. 3, PDF).
When considering the costs, two cases are distinguished: Firstly, the short-term benefit due to the often less costly suboptimal solution, and secondly, the additional long-term cost due to the suboptimal solution (Fig. 4, PDFIn this context, TD causes significant, on average, unplanned expenses that outweigh the short-term benefits.
Visualization for early warning of TD and cost estimation
To identify the risks of high subsequent costs associated with technical development (TD) early on and to make the decision to implement TD more consciously and with knowledge of the anticipated costs, it is necessary to visualize it (Fig. 5). Especially with TD between different disciplines or different life cycle phases, visualization allows for greater transparency across cost centers. A traffic light function indicates the criticality of the TD. Using the example of the incorrectly wired robot, the visualization illustrates the additional costs for the software discipline for one or more systems (see Fig. 5)., PDFOnce a plant has been commissioned, deliberately chosen TDs can only be replaced with the more complex optimal solution with considerable effort.
In order to visualize such cost estimates, the TD must be gradually integrated into the post-calculation, thereby iteratively improving the data basis.
Conclusion and Outlook
In traditional software engineering, technical documentation (TD) is a well-known phenomenon. However, due to the additional disciplines of mechanics and/or electrical/electronic engineering involved, it cannot be readily transferred to the software engineering of electronic systems (ES) and mechatronic systems, particularly in mechanical and plant engineering. The impact of TD across disciplinary boundaries also warrants further investigation in future research. The necessity of this research is illustrated in this paper using the example of a miswired robot and the resulting technical damage and financial losses. Initial proposals for how such TD can be visualized in the future are presented. A survey conducted specifically for this paper demonstrates that the long-term additional costs resulting from a suboptimal solution outweigh the short-term benefits. The findings can help industrial companies reduce the number of TDs during the commissioning of a production system and eliminate them in existing, similar systems. This could reduce maintenance costs and increase the companies' profitability. To improve the classification of TD, we were able to examine two additional case studies in more detail in preliminary work [4, 5] and plan to expand this with further case studies in the future.
Link to the survey: https://umfrage.ais.mw.tum.de/index.php/947666?lang=de
Bibliography and list of sources
[1] W. Cunningham, “The WyCash portfolio management system,” ACM SIGPLAN OOPS Messenger, vol. 4, no. 2, pp. 29–30, 1993.
[2] B. Vogel-Heuser and S. Rösch, “Applicability of Technical Debt as a Concept to Understand Obstacles for Evolution of Automated Production Systems,” in 2015 IEEE International Conference on Systems, Man, and Cybernetics, 2015, pp. 127–132.
[3] T. Besker, A. Martini, M. Tichy, and J. Bosch, “An investigation of technical debt in automatic production systems,” in Proceedings of the XP2017 Scientific Workshops on – XP '17, 2017. In press.
[4] L. Capitán and B. Vogel-Heuser, “Metrics for Software Quality in automated Production Systems as an Indicator for Technical Debt,” in 2017 IEEE International Conference on Automation Science and Engineering (CASE), 2017. In press.
[5] B. Vogel-Heuser and E.-M. Neumann, “Adapting the concept of technical debt to software of automated production systems focusing on fault handling, modes of operation, and safety aspects,” in Proceedings of the 20th World Congress of the International Federation of Automatic Control (IFAC), 2017. In press.
[6] Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on technical debt and its management,” Journal of Systems and Software, vol. 101, pp. 193–220, 2015.
[7] 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, vol. 131, pp. 35–62, 2017.
authors
Thomas Aicher is a research associate at the Chair of Automation and Information Systems at the Technical University of Munich. His research interests lie in the model-based development and flexibilization of control software for mechatronic systems.
Quang Huan Dong is a research associate at the Chair of Automation and Information Systems at the Technical University of Munich. His research interests include the analysis of technical debt in mechatronic systems and its short- and long-term effects.
Prof. Dr.-Ing. Birgit Vogel-Heuser She heads the Chair of Automation and Information Systems at the Technical University of Munich. Her research focuses on the development and system evolution of distributed intelligent embedded systems in mechatronic products and production facilities. She is the spokesperson for the Collaborative Research Center (CRC) 768 "Cycle Management of Innovation Processes" and a member of acatech.
Contact
Internet: www.ais.mw.tum.de
Email: {thomas.aicher; huan.dong; vogel-heuser}@tum.de
Management – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topics of management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Management – Expertise
Valuable expertise in management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
