Abstract
Abstract Functions of automated Production Systems (aPS) can be realized by control software (SW), whose high quality and short development time are, therefore, vital. To achieve both, SW should be modular and, thereby, reusable. Static code analysis can help improve the modularization of existing software, e. g., by automatically analyzing control and information flow. However, manual code reviews are still typically required because planning a SW’s modularization requires a semantic understanding of its functionality. This paper presents an approach to, instead, identify SW functionality automatically and evaluates it with SW from three aPS manufacturers.
Highlights
Functions of automated Production Systems can be realized by control software (SW), whose high quality and short development time are, vital
The SW is typically executed on Programmable Logic Controllers (PLC) and implemented according to IEC 61131-3, which defines five programming languages and so-called Program Organization Units (POU) to structure the SW [2]
The presented concept is prototypically implemented as part of the ZD.B-funded project advacode, focusing on PLC SW developed in Siemens Totally Integrated Automation (TIA) V15.1 and V16
Summary
Functions of automated Production Systems (aPS) can be realized by control software (SW), whose high quality and short development time are, vital. Static code analysis can help improve the modularization of existing software, e. The majority of industrial and consumer products are manufactured or processed by automated Production Systems (aPS) whose functions are primarily and increasingly realized by control software (SW) [1] (Note that “function” in this paper describes any goal-oriented behavior, whereas “functionalities” can be differentiated based on their specific purpose). G., by categorizing library POUs to assemble new configurations or by helping to improve the modularity of existing SW [4]. This semantic understanding requires in-depth manual analyses of a POU’s description Modularity improvements can focus on limiting functionalities to specific levels in the call hierarchy, prescribing which functionalities should be fulfilled by distinct POUs, or restricting permissible relations (e. g., only allowing data exchange between selected functionalities)
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
