Cyber-physical products promise more innovative power and process efficiency. System-driven innovation processes can significantly support companies in their development. However, these require specialized applications and a flexible IT architecture. […]
Modern cyber-physical products are based on a combination of digital and real components and are created by the interaction of various engineering disciplines and expert systems, whose complexity and networking are constantly increasing. Due to the trend towards multi-variant and customer-specific products, it is becoming increasingly important to map the relationships between requirements, solution architectures and optimization cycles with simulation and verification in a digital thread (relationship network) in order to increase process efficiency and innovative strength (see Figure 1).
In the course of Industry 4.0, products are increasingly gaining digital capabilities with data-technical networking. Such intelligent, cyber-physical systems (CPS) consist of three core elements:
- Physical components (mechanical, electronic, etc.)
- Smart components (e.g. sensors, microprocessors or analytics)
- Connectivity (data connection, for example to a cloud)
Figure 1: System-driven development structures in the digital thread relationship network (c) Fernfachhochschule Schweiz
Products with new digital capabilities
CPS products are therefore not only mechanically modeled in 3D, but also have a mechatronic character, have intelligence and can communicate via a data connection. This enables new digital capabilities: things can be remotely monitored and controlled, for example, regardless of location – without having to be physically at the product. In addition, products can be further optimized and automated.
Instead of the previous product delivery as the basis for invoicing, the effect of a product becomes the focus of billing models. Companies are increasingly developing digital business models for this purpose. An example of this is the “power-by-the-hour” model of the British engine manufacturer Rolls-Royce. Manufacturers are no longer obliged to buy the turbine engine, but only pay for the operating hours.
High-performance CPS products are made possible on the one hand by a higher proportion of software and electronics compared to mechanics and by a greater product complexity. On the other hand, new solutions have to be found again and again, especially in the innovation and development processes, and new paths have to be taken, which requires a greater need for coordination between the engineering disciplines.
In the beginning there are the requirements
The starting point of every development is the clarification and recording of the requirements, which should be defined as systematically as possible in the form of requirement objects. Based on product requirements at a higher-level business and marketing level as well as from the point of view of product use, requirements are broken down into more precisely formulated technical requirements – depending on the methodology used – and the input of several teams is collected. As a result, a requirement structure is created over possibly several levels. From this, individual requirements can be linked to solution elements. And the classic list of requirements for a product can also be generated as a document via a report.
The next step is a functional analysis for the product to be developed, for which the overall function must first be determined (for example, “converting torque” for a gearbox). After that, the overall function is gradually decomposed in a top-down construction method in order to obtain the individual target functions of the product. These are formulated in a solution-neutral way, so that it remains to be seen which engineering discipline is selected for the solution (electronics, mechanics, etc.).
From the virtual to the physical
After that, the entry into the solution finding process takes place, for which, at the logical level, active principles are considered in order to be able to assign a solution to the functional elements (if necessary, using the morphological box). At the beginning, this is not very detailed, but it is already possible to see which discipline is being considered (e.g. electric motor). This logical level of abstraction is necessary to find optimal solutions for the target functions. In general, this is not possible directly at the part level, since a function cannot be solved by an individual part, but a pair of effective surfaces of several parts is required.
The so-called 1D simulations must also be arranged on this logical abstraction level in order to secure properties as early as possible through virtual tests. Finally, the transition to the physical part level can take place, whereby a concrete solution in the form of individual parts or assemblies is assigned to the logical solution elements. The well-known CAD models, continuous 3D simulations (FEM: Finite element Method, CFD: Computational Fluid Dynamics, MKS: Multibody simulation) and the product structure definition as an engineering BOM (design BOM), which is required in the further downstream process, are located at this concretization level.
The procedure methodology described above for these four levels is referred to in English by the abbreviation RFLP (Requirements, Functional, Logical, Physical) and belongs to the domain of so-called Model Based Systems Engineering (MBSE). The application of such a methodology is recommended whenever a complex problem has to be mastered or when a completely new solution approach is required for a task. Special system modeling applications have established themselves in the IT landscape for this purpose, the integration of which into enterprise IT is a special challenge due to its interdisciplinary nature.
Figure 2: Intelligent cyberphysical products, illustrated on the five-level model of IoT technology (c)
IT architecture for system-driven innovation
Powerful requirements engineering applications are available for handling requirements. At the same time, the enterprise IT systems have data model extensions for requirements – above all the product lifecycle management systems (PLM). Due to their central importance, the entirety of the product requirements should always be available in the PLM system, whereby partial aspects such as pure software requirements can also be maintained in an application lifecycle management system (ALM) and synchronized with PLM.
For system models, it should be noted that although they are created by system engineers, they are not only the result of the work of a discipline, but also occupy a central special position in the interdisciplinary engineering process. The contents of the system model describe conceptual approaches to solutions and the division of tasks between the engineering disciplines involved. That is why they are needed as objects to orchestrate the interdisciplinary development process across teams and departments. Similar to the structural information content of CAD systems (consists of / contains relationships), the system model is thus not only stored as a document, but also synchronized at the object level.
However, the central difference compared to CAD integrations is the detailed and highly varying system modeling on an abstract level, which is only understood in depth by system engineers anyway. Therefore, a rigid 100 percent synchronization is not useful for the integration of system modeling, but a flexible overlay approach is preferable, where meaningful anchor elements can be specifically selected for synchronization in a product model, depending on requirements. Unimportant detail objects are not synchronized and are only visible to the discipline. The main advantage of such an overlay approach are highly efficient innovation processes that allow completely flexible digital thread characteristics across the disciplines involved – including the verification of required properties through parameter-controlled simulations.
Companies with the goal of developing high-performance CPS products can significantly increase their innovative strength by introducing system-driven innovation processes and consistently supporting them with specialized applications and a flexible IT architecture. This not only enables better and smarter products, but also significantly higher process efficiency in the company. This will become increasingly important for variant-rich or customer-specific products and market success in the future.