Automation software architectures in automated production systems: an industrial case study in the packaging machine industry

The current technological advances in production engineering require highly-flexible, evolvable machines and equipment combined to so-called automated Production Systems (aPS) [1]. Nowadays, the evolution of aPS is predominantly realized via software and thus places high demands on control software architecture. While there are numerous software architecture (SWA) analysis approaches in the embedded systems area, this field has been hardly researched for control software architecture in aPS (CSWA). The hard real-time requirements, lifecycles of several decades, and code change during runtime of the operating machine [2] hamper the development of universal guidelines for high-quality architecture. However, a cleanly modularized, evolvable, and maintainable CSWA is the key to implementing future-oriented technologies and, thus, staying competitive.

A major challenge in improving CSWA often lies in recognizing influences between design decisions and identifying concrete starting points for optimization. This paper, therefore, presents an approach to define CSWA for aPS based on previous analyses of industrial use cases, including five architectural views for considering influencing factors on CSWA. Using an in-depth industrial interview study with renowned control software experts of three packaging machinery companies, the suitability of CSWA types for different company-specific boundary conditions and production processes is investigated. Templates for documenting architectural design decisions are introduced to visualize the connections, drivers, and consequences to derive recommendations for improving the architecture. The benefits of the architecture analysis and the derived recommendations are proven in follow-up meetings with the interviewed experts.

In the following, first, the state of the art of analyzing SWA is introduced (Sect. 2) to derive a definition for CSWA (Sect. 3). Section 4 introduces morphological boxes to structure influencing factors on CSWA. Section 5 defines templates for documenting design decisions and formulating recommendations for action used for the interview study described in Sect. 6. The paper closes with an outlook in Sect. 7.

The following subsections outline the state of the art of control software in aPS and analyzing SWA.

The basic elements of SWA definitions in computer science can be also be found in CSWA. Components can be POUs (individual ones or groups arranged to modules), actions, variables, or OO-IEC elements (e.g., properties or methods), which are connected by data exchange (calls or reading/writing variables) or by structural connections resulting from OO-IEC, i.e., inheritance or interfaces. However, the core characteristics of CSWA, such as the need for hard-real time and software changes during operation, are not considered in definitions from computer science [2]. To address this gap, representative control software projects and architectural guidelines of three companies with different boundary conditions are compared (cf. Table 1), i.e., a packaging machine manufacturer (A) with mature CSWA and quality management as proven in a preceding questionnaire study [10], a plant manufacturer (B) from automotive applying precise programming guidelines to ensure high software quality, and a plant manufacturer from the field of wood industry (C).

The results show that CSWA is strongly influenced by the particularities of aPS elaborated and confirmed in preliminary work [2] and is mainly determined by design decisions in the following architectural views, i.e., specific subsets of the system's structural elements [14].

Hardware influences on hierarchy and modularization The significant hardware complexity in aPS and the long lifetime require mature CSWAs to enable evolvability during the system’s operation via software changes during runtime [2]. Depending on the aPS size and motion tasks, different automation hardware architectures are required (e.g., usage of multiple PLCs or sophisticated drive technology), which also strongly influence the CSWA.

Extra-functional tasks Extra-functional tasks such as exception handling, connection to the human–machine interface (HMI) or operation mode switching account for up to 75% of an control software project [15]. These tasks are usually modularized differently from the functional software parts but are also closely coupled with them, making variability management for CSWA a major challenge [16].

Programming paradigm and software development Software changes during operation are often carried out by technicians with little programming background making it difficult to apply object-oriented programming paradigms that are standard in computer science [2]. In addition, certain OO-IEC constellations can cause runtime issues and thus conflicts with the hard real-time requirements of aPS [17].

Company-specific boundary conditions This is not an architectural view per se since company characteristics cannot be mapped directly to the software. However, company-specific boundary conditions, e.g., the workflow of interdisciplinary cooperation [4], strongly influence CSWA.

Summarizing, the consensus of SWA definitions from computer science is not sufficient to define CSWA. Thus, to understand and optimize CSWA, the definition is enlarged by the architectural views as introduced above.

Since the analysis and comparison of architectural design decisions is a multidimensional problem, morphological boxes are introduced to describe different architectural views. The morphological boxes are derived from previous industrial case studies [10] and substantiated by consultations with experts from academia and industrial automation.

While there is a broad consensus in high-level language software on desirable design principles leading to high quality (cf., e.g., [18]), the definition of universal best practices for CSWA in aPS is challenging due to company-specific differences in the understanding of software quality and various stakeholders with different background working on the software (Table 2). In plant and special-purpose machinery, e.g., technicians with little programming skills often need to change software under time pressure during commissioning, thereby potentially impairing CSWA in case it is not intuitively understandable. Experience of industrial code analyses shows, e.g., that larger companies, especially when operating at multiple locations, are more urged to cleanly modularize and document the software since an exchange "on-demand" during development is hardly possible, e.g., to compensate for difficult-to-understand code fragments. Depending on the industry, there can be specific standards (e.g., OMAC for packaging machines) or legal requirements (e.g., in the medical sector) that require or support the maintenance of a high-quality CSWA (cf. Table 2). Safety-related standards such as the Good Automated Manufacturing Practice 5 (GAMP 5) in the pharmaceutical and food industry enable risk assessment throughout the system’s lifecycle to ensure product quality and safety. Certification according to GAMP requires the fulfilment of design specifications by the CSWA and the integration of validation procedures into the system’s development workflow.

Regarding hierarchy and modularization, experience from previous case studies [10] shows that machines, which are expendable by well-defined reusable stations to address different customer needs, also require a well-modularized CSWA (cf. Table 3). Unlike direct data exchange via POU interfaces and calls, indirect data exchange via global variables often inhibits reusability. A hierarchical CSWA structure is generally rated as beneficial. Structuring the CSWA towards the physical layout of the aPS enhances the system’s understandability and thus facilitates its evolution and maintenance [10].

Copy, Paste & Modify is rated to have a strong negative effect on the CSWA (cf. Table 4) due to the reasons derived in Sect. 3. On the other hand, systematically reusing control software, e.g., using templates, libraries, or code generation, is expected to enhance CSWA quality.

Documenting and, thus, understanding industrial CSWA design decisions requires a comprehensible form of presentation that provides a quick overview of the design decision itself, the drivers leading to it, its consequences, and where to find it in the software. Therefore, the following four-part template is proposed (see Fig. 1).

Analyzing the design decisions and their consequences allows a clear understanding of the strengths and weaknesses of the existing CSWA to identify starting points for CSWA improvement and to assess influences between planned adaptations and the design decisions already made. Therefore, understandable recommendations for action are required, which cover the following aspects that are based on [19] and enlarged by precise categories for the individual aspects (Table 5):

The applicability of the architecture analysis using the templates of Sect. 5 and the assumptions on influencing factors on CSWA (cf. morphological boxes in Sect. 4) are analyzed by conducting expert interviews in three aPS manufacturing companies.

This paper proposes a definition of CSWA by introducing architectural views that consider the particularities of aPS affecting control software [2], including the complexity of hardware layout and motion tasks, the need to adapt to changes during operation, and the challenges of implementing extra-functional tasks. The impact of the architectural views is examined with experts from academia and industrial automation based on morphological boxes. To analyze and enhance industrial CSWA, templates are defined to document and analyze architectural design decisions and their impact and formulate concrete recommendations for action to enhance an existing CSWA. The benefit of the templates is demonstrated by an industrial interview study in three packaging manufacturing companies, and the identified design decisions in different architectural views are compared and discussed.

The positive feedback from the experts in the interview study shows the great potential of a systematic architecture analysis to optimize existing software and enable the implementation of pioneering technologies in production engineering. Therefore, future research will analyze how such an architecture analysis can be integrated into the industrial software development workflow. Especially for small companies, it is financially and capacity-wise unrealistic to set up separate departments for systematic quality management, so their empowerment to optimize CSWA with given resources efficiently will be the focus of future research. Currently, the analysis is done manually, but there are already considerations regarding which aspects of the analysis can be automated to facilitate the implementation in industrial practice. This could, e.g., identify violations of existing architecture specifications. In addition, the combination of different views in the architecture assessment and the resulting knowledge about influences between design decisions can support the development of new software projects in the design phase with best practices and design patterns.