Analyzing the industrial scalability of backwards compatible intralogistics systems

Abstract

The (re-)development of industrial production systems has to deal with high flexibility due to customers' demands as well as constraints such as the dimensions of the manufactory. Therefore, Intralogistics systems, which transport goods or products between machine tools in the production system, must also be flexibly assembled to fit into the given space. This presupposes that parts of the Intralogistics system, such as a belt conveyor, may be modified or exchanged by different ones and with less effort. Additionally, due to the different lifespans of mechanical, electrical and software components, often electrical devices need to be replaced by other ones during operation as a result of lacking availability thanks to shorter life cycles. Nowadays in industry, a manual adaptation of the control software is necessary after the exchange of an electrical/mechanical device with a newer one. In order to ease the software adaptation, in this paper an automatic analysis of the differences between incompatible software and an adaptation approach focusing on the functional behavior of the software is introduced. After identifying seven interaction points of the control software that need to be adapted, the approach is evaluated with an industrial case study and feedback from industrial experts to prove industrial scalability.

A Runtime Adaptation Concept to reinforce Versatility in Industrial Automation

“…Furthermore, other approaches as in [35] and [75] propose a scheme to increase the reconfigurability of material flow systems. Moreover, an automated analysis scheme is shown in [5] that interlinks both layers the field and control layers. The objective of this automated analysis comes handy during the exchange of field devices.…”

“…Special graphs that contain symmetries, e.g., ring, star, Petersen, etc., can have a formula to calculate the optimal transfer factors α as shown in [15] or can be approximated using regression models as presented in Sec. 5. 5.…”

“…The request is sent to the best candidate node, i.e., the node with the highest negative deviation to the mean, as well as satisfies the requirements and boundary conditions, e.g., communication QoS and required Node to Device (N2D) topologies. 5. The maximum capacities of the node resources are considered.…”

Industrial Cyber-Physical System Evolution Detection and Alert Generation

“…Although the identified issues are motivated by a press line domain, we notice that the ICPS evolution is something known in the literature [13,14], and considering the domain analysis performed in our previous work [5], we realized that ICPS evolution besides the different ICPS topologies are not specific problems for press lines. In the literature, many authors consider software evolution [14][15][16][17], but very few of them consider software and hardware evolution [18,19] even though those who consider runtime variability do not consider uncertainties; hence, as far as we know, no one in the literature has give the response to detecting ICPS evolution in order (1) to have the traceability of what has happened in an ICPS over time; (2) to classify the occurred evolution in order to communicate immediately to the users to avoid any bad decisions; and (3) to give a solution which considers different ICPS topologies.…”