Life Cycle Engineering Management of Intelligent Industrial Systems

Industrial digitalisation combines sensors, connected equipment, analytical platforms, automation, and artificial intelligence (AI), but these technologies should not be treated as a single intervention. Their data requirements, interfaces, responsible actors, and expected operational effects differ substantially. Reviews of smart manufacturing therefore emphasise the need to connect technology choices to specific production functions and measurable outcomes [1], while research on industrial AI distinguishes process monitoring, optimisation, control, and decision support rather than assuming a uniform effect across applications [2].

A life-cycle perspective extends this distinction from the initial business need to system retirement. Product life-cycle management research shows that AI can support design, manufacturing, maintenance, and knowledge reuse [3], and a digital life-cycle framework can connect sustainability objectives with decisions made in energy-intensive manufacturing [4]. At the operational stage, predictive diagnostics can support maintenance planning [5], and hybrid monitoring and optimisation can reveal opportunities to improve existing machining lines [6]. These studies establish relevant mechanisms, but their measures are usually system- or site-specific and cannot automatically be transferred to company-level comparisons.

The same measurement problem applies to economic, environmental, and workforce outcomes. Intelligent manufacturing has been associated with green innovation and manufacturing development [7], and data-driven systems have been proposed for energy-saving resource management [8]. Human-in-the-loop research additionally stresses that technical performance depends on task allocation and operator participation [9], while organisational research identifies employee digital literacy as a condition of effective transformation [10]. Recent analysis of AI combined with production technologies likewise shows that outcomes depend on the application, integration architecture, and industrial context [11]. Consequently, absolute values for energy, cost, downtime, quality, or safety are not comparable unless their definitions, observation periods, baselines, and denominators are aligned.

The literature provides extensive descriptions of technologies and individual benefits, yet it offers less guidance on how engineering managers should connect each life-cycle decision to an auditable indicator and a traceable evidence source. Corporate disclosures add practical examples but often describe intended benefits without reporting plant-level baselines or calculation inputs. The present study addresses this gap by separating evidence that a system and function are documented from evidence that the system caused a measurable outcome.

The aim was to develop a life-cycle engineering-management framework and use four industrial cases to examine how publicly documented intelligent technologies, management tasks, indicators, and evidence limitations can be mapped consistently. The study addressed three research questions:

RQ1. How do the technologies and intended functions documented in the four cases differ across life-cycle stages?

RQ2. What definitions, baselines, denominators, and source details are required to compare performance indicators?

RQ3. How can these requirements be organised into a framework for engineering-management decisions?

The research design was a descriptive multiple-case study based exclusively on public secondary data. The study did not estimate treatment effects, calculate company performance, or test differences among companies. For this study, an intelligent industrial system was defined as a connected digital system that uses sensing, industrial data, automation, analytics, or AI to support or execute decisions within an industrial process. A case was eligible when a named technology, an industrial application, and a traceable official source were available. General statements about corporate digital strategy without an identifiable system or process were excluded.

Siemens, Atlas Copco, Vallourec, and thyssenkrupp Materials Services were selected through maximum-variation sampling rather than as a statistically representative sample. Together they cover industrial automation, compressed-air equipment, tubular products and services, and materials logistics, and they document different technical configurations and deployment contexts. This variation was useful for testing whether the same life-cycle decision structure could organise heterogeneous cases.

A targeted source search covered peer-reviewed publications dated 2020–2025 and official corporate disclosures dated 2019–2025. Search combinations included “intelligent manufacturing”, “smart manufacturing”, “industrial AI”, “predictive maintenance”, “life-cycle management”, “engineering management”, “performance indicator”, and each company name with the name of its disclosed technology. Publisher pages and DOI records were used for academic-source verification, and official company websites were used for case evidence. The final source check was completed on 10 September 2026.

Sources were included when they directly addressed intelligent industrial systems, life-cycle decisions, implementation risks, or measurable industrial performance and provided sufficient bibliographic or webpage information for verification. Sources focused on unrelated applications, unpublished materials without stable provenance, duplicate records, and company homepages lacking case-specific information were excluded. The retained official case sources were a Siemens press release on Industrial Copilot [12], the Atlas Copco SMARTLINK system page [13], a Vallourec account of its Smartengo solutions [14], and a thyssenkrupp Materials Services release on the alfred AI platform [15].

A structured extraction matrix recorded the company and sector, observation year, named technology, technical components, production or service area, reported deployment scale, life-cycle stage, intended function, responsible actor, performance indicator, unit, baseline, follow-up period, denominator, and exact source location. Information not stated in the source was coded as “not reported”; no missing value was imputed. If sources differed, the more specific and more recent official source was prioritised, while unresolved numerical conflicts were excluded rather than averaged.

The comparison used qualitative pattern matching across five stages: planning, design, integration, operation and support, and upgrade or retirement. A function was mapped to a stage only when the source described a corresponding activity. The analysis reports the presence and scope of documented functions, not their magnitude or causal effect. One-way analysis of variance was not applied because each company did not provide replicated observations from comparable years, plants, or projects, and the within-group variance required for that test could not be estimated.

Economic indicators were defined before use so that future applications of the framework can be reproduced. Return on investment is defined as ROI (%) = $[(B - C) / C] \times 100$, where $B$ is the monetised benefit and $C$ is the total investment cost over the same evaluation period. Net present value is defined as NPV = $-I_{0} + \sum_{t=1}^{n}\frac{\mathrm{CF}_{t}}{(1+r)^{t}} + \frac{\mathrm{RV}_{n}}{(1+r)^{n}}$, where $I_{0}$ is the initial investment, $\mathrm{CF}_{t}$ is net cash flow in year $t$, $r$ is the discount rate, $n$ is the evaluation period, and $\mathrm{RV}_{n}$ is residual value in year $n$. Total cost of ownership is defined as TCO = $C_{\mathrm{acq}} + C_{\mathrm{inst}} + C_{\mathrm{int}} + C_{\mathrm{train}} + C_{\mathrm{soft}} + C_{\mathrm{maint}} + C_{\mathrm{energy}} + C_{\mathrm{upg}} + C_{\mathrm{disp}} - \mathrm{RV}_{n}$, covering acquisition, installation, integration, training, software, maintenance, energy, upgrades, disposal, and residual value.

Operational and environmental indicators were expressed as rates or intensities rather than absolute totals whenever comparison was intended [16]. Environmental intensity metrics require a defined functional unit and consistent system boundary [17], while workforce indicators require exposure or participation denominators instead of undefined percentages [18]. A conventional life-cycle assessment, system-dynamics simulation, and multi-criteria analysis were not performed. Such extensions would respectively require a functional unit and inventory, model variables and equations, or explicit criteria, weights, normalisation, and scores [19], [20].

The research process therefore comprised four transparent steps: source identification, eligibility screening, structured data extraction, and cross-case mapping to the five-stage framework. This sequence makes clear which statements originate from public evidence and which elements are analytical classifications developed in this study.

Table 1 identifies the technology examined in each case and the precise location of the supporting corporate disclosure. The sources document the existence, intended function, and reported deployment context of the systems, but they do not provide a common set of plant-level pre-implementation and post-implementation outcomes.

The four cases cannot be represented as observations of the same treatment. Siemens documents a generative-AI assistant for engineering and manufacturing tasks, Atlas Copco describes sensor- and cloud-enabled monitoring of compressed-air assets, Vallourec reports a portfolio centred on traceability and operational support for tubular products, and thyssenkrupp Materials Services documents AI-supported logistics decisions. The technologies differ in unit of analysis, user group, production context, and deployment maturity. Accordingly, the comparison identifies functional patterns but does not rank one company as performing better than another.

The cross-case mapping supported a five-stage structure that separates management decisions from systems-engineering tasks (Figure 1). Planning establishes the problem, system boundary, and business-case assumptions, design specifies architecture and data requirements, integration coordinates technical interfaces, commissioning, training, and security, operation and support monitor performance and model behaviour, and upgrade or retirement compares continued maintenance with replacement and governs data migration and disposal.

Table 2 operationalises the figure for engineering management by linking every stage to a decision, a systems-engineering task, responsible actors, an indicator, and a principal risk. This linkage is the main analytical framework produced by the study.

Table 3 replaces undefined percentages and absolute company totals with operational definitions and minimum data requirements. A value is comparable across cases only when the numerator, denominator, observation period, system boundary, and calculation rule are equivalent. Otherwise, it should be reported within a case and accompanied by an explicit warning against ranking.

The public case sources did not provide these inputs in a harmonised form. In particular, they did not jointly report baseline and follow-up values, equivalent plant or production boundaries, consistent measurement periods, or output-based denominators. The previously reported absolute values and percentages could therefore neither demonstrate improvement nor support cross-company statistical comparison. Their exclusion prevents differences in production volume, asset age, product complexity, or reporting practice from being misinterpreted as technology effects.

The term “intelligent system” is shown to include essentially different configurations. Siemens focuses on generative AI in engineering applications, Atlas Copco on connected asset monitoring and service support, Vallourec on traceability and operational applications, and thyssenkrupp Materials Services on AI-supported logistics. This heterogeneity is consistent with the view in the literature that intelligent manufacturing should be analysed by its specific functions and interfaces [1], [2], [11]. It further explains why the descriptions available do not allow for inferring a single company-level “degree of integration”.

The cases show evidence of technologies being deployed or offered alongside intended operational objectives but do not demonstrate that the systems led to changes in productivity, quality, resilience, energy use, emissions or workforce outcomes. They could all produce the same observed differences—production volume, asset replacement, plant age, product mix, maintenance policy, staff restructuring, energy prices and regulatory changes. Also, the corporate sources are self-reported and have different units of analysis. These factors need to be cautiously interpreted and exclude cross-company ranking and inferential analysis with the existing evidence.

The engineering-management contribution is the formal linkage of a life-cycle decision with the evidence that supports that decision. At planning, the managers should approve a system boundary, baseline, evaluation period, and acceptable investment and integration-risk limits before authorising expenditure. Document interface compatibility, data quality, oversight by humans, training coverage, commissioning disruption, and cybersecurity tests at design and integration. During operation, measures of downtime, quality, energy, environmental, data-reliability and safety should be monitored against pre-specified thresholds. When upgrading or retiring, consider the life-cycle cost over a consistent period, including residual value, data migration and disposal, versus continued maintenance.

This structure makes it possible to trace the recommendations to the analysis. Pilot deployment is appropriate at the integration stage only when the pilot has a stated baseline, comparison period, acceptance threshold and data owner. When interface tests and change-control responsibilities are specified, modular architecture is useful. Training should be measured as coverage of eligible users and tied to tasks. Operational review should differentiate between technical failure, data failure, and model drift. Organisational and technical barriers can impede intelligent-system projects and connected industrial systems require explicit consideration of human-error and cybersecurity controls [21].

The framework also makes clear what role more demanding analytical methods play. To perform a prospective environmental life-cycle assessment, a functional unit, system boundary, inventory, allocation rules and impact categories are necessary. A system-dynamics extension would require a causal structure, equations, parameters and validation data, whereas a multi-criteria analysis would need transparent criteria, weights, normalisation and sensitivity analysis [19], [20]. These methods may enhance future evaluation, but to name them without their procedures or outputs would exaggerate the current study.

Its main limitation is its reliance on a small purposive set of public corporate disclosures. The cases are not representative of all industrial sectors and the sources varied in date and detail of disclosure. The data available for plant-level analysis were not independent. Future research should include longitudinal observations before and after implementation, at a consistent unit of analysis, should report sample sizes and uncertainties, and should use matched comparisons or longitudinal models only when their assumptions are met.

This descriptive multiple-case study demonstrates that publicly documented intelligent industrial systems differ in technology, deployment context, users, and intended function. The available evidence supports the identification of these functions and their placement within a life cycle, but not causal claims, statistical significance or rankings based on absolute economic, production, environmental or workforce values. Comparing performance indicators across cases requires explicit definitions, baselines, denominators, evaluation periods and source locations.

The proposed framework structures planning, design, integration, operation and support and upgrade or retirement around a specific management decision, systems engineering task, responsible actor, performance indicator, and risk, thereby organising these requirements into a coherent engineering-management framework. The practical value of this is that it demands specifications of definitions, baselines, denominators, evaluation periods and source locations before any performance claims are made. It can help managers with investment decisions, interface coordination, operational monitoring and system renewal, and assist researchers in designing reproducible plant-level evaluations.