Mastering and optimizing the product lifecycle requires integration across the domain/application area, business unit and product line dimensions along the product development process and represents a significant competitive advantage. Many IT projects that are looking at a PLM Implementation are still approached as if classic IT products such as CAx, PDM or ERP systems were being introduced. The design of a PLM architecture, which is necessary for a PLM, is usually only carried out at the system development level. However, one of the central challenges in the development of a PLM architecture is the conception of the integrated product models interacting in the PLM architecture. In order to be able to develop these, a conceptual system is necessary which is developed within the framework of the DoPLMCon method of Prof. Fischer was developed. The following article explains this methodical conceptual system and explains how it can be used for implementation in a PLM architecture.
Original source:
FISCHER, Jörg W.; Brinkmeier, Bernd:
Do(PLM)Con - Proposal of a systematics for the development of PLM architectures.
In: ProductDataJournal,
Darmstadt, 19(2012)1, pp.24-28.
(ISSN: 1436-0403)
Current state of discussion on the development of PLM architectures
The necessity of mastering the product lifecycle and the competitive advantages that arise from this have been recognized by many companies. Consequently, the industry is working on developing and implementing future integrated PLM architectures (see Sendler, Wawer 2011, p. 41 ff., Fischer et al. 2011). A key task here is to define a suitable IT system architecture that can implement this approach and to implement it technically in an evolutionary process, taking into account the existing system architecture.
One ideal concept discussed in this context (see Fig. 1) is to loosely couple the IT systems involved via a service bus. The idea pursued by this approach is to have each of the IT systems offer standardized "services" that can be used by the other IT systems involved. The view shown in Figure 1 is functionally driven. It assumes that each system can provide defined functions (the services) that can then be used by another system. However, this ideal is not realistic.
Product models are built up in the product development process. These are usually mapped in the form of product structures in IT data management systems. The IT functions used in product development traverse the respective product model and extract the data to be processed. To do this, they require specific semantics that the product models must fulfill. If these semantics required by the functions are not fulfilled in the model, the respective function is not available or only available to a limited extent (see Fischer et al. 2011, p. 18 ff.). This problem is particularly relevant in the development of integrated PLM architectures, since the integration influences the semantics of the integrated models.
Figure 2 shows an example of a typical industrial integration scenario. The goal in setting up this scenario is to provide a digital product prototype that is correct for storage and can be configured based on options that can be selected by the customer. The use case is implemented within the PDM system. The application functions, such as visualizing the virtual prototype, take place in the PDM client.
To implement this, model extracts from the configuration system are introduced into the product model of the PDM system (Fig. 2, detail A). In this specific case, this involves the items, the item variants, the parts, and the usage including the variant condition. A data transformation takes place between the data model of the source system and the data model of the target system. To complete the model, the introduced model extracts must be semantically integrated. In the example case, the semantic integration is performed by manually assigning the CAD documents to the respective uses and supplementing geometric variance that has not yet been explicitly documented. The information content supplemented in this way has its own life cycle and must be persistently maintained. This procedure creates the information technology basis for the new use case.
The actual use case is performed by the user with the help of IT applications. The applications (in the example case the PDM client, see Fig. 2, detail C) access the product models mapped in the data management system, extract a scope for processing and make the data available to the user. However, this only works if the semantic consistency that the respective PDM client requires from the product structure in the PDM system is maintained. The case described shows that when designing integrated PLM architectures, the semantics of the models must be carefully planned beyond the functional view and their semantic consistency must be maintained against the background of the desired functional realization.
In current implementation projects, there is usually no systematic, model-semantic discussion. The functional view that has generally been taken so far often leads to the problem that integrated models are created in the course of the project, but their model semantics and semantic integrity are laboriously adapted by trial and error until they fulfill their purpose.
The main reason for this is the lack of suitable methods for systematically designing integrated product models. To remedy this situation, Siemens PLM developed the Do(PLM)Con methodology as part of an industrial research project (see Fischer et al. 2011). In addition to methods for designing integrated PLM architectures, it provides a conceptual system that allows the topic under investigation to be discussed in a methodologically abstract manner. In the following, some essential parts of this conceptual system are presented.
Submodels and carrier systems
DoPLMCon follows a model-based approach and consistently separates "abstract" (partial) product models (in short: partial model) and their realization in carrier systems (e.g. PDM system, ERP system, etc.).
The terminology of the submodel is based on the model understanding of VDI 3633, p. 3. According to this, a model is a representation of a system with its behavior in another conceptual or objective system. In doing so, it reproduces the relevant properties with sufficient accuracy for the respective purpose. A submodel in a PLM architecture is therefore a closed scope of information that represents a partial aspect of the product, can be summarized at the methodological level and is intended to cover specific use cases of the technical business process.
In product development, different (partial) product models are depicted that reflect different aspects of the real product. A typical example is the virtual prototype (for examples of possible partial models see e.g. Eigner Stelzer 2009, p. 79).
Figure 3 (Detail A) summarizes some essential aspects for the definition of submodels within the Do(PLM)Con method. A submodel exists because of its use cases (Figure 3, Detail A, Business Intent). To realize these, it must cover specific use cases of product development. The data contained in the submodel for the realization of the use cases are subject to semantic requirements (Semantic). Semantics is subdivided into the areas of information entities to be stored, relations between the information entities, and the basic organizational structure in the model. A submodel is geared to a specific scope of product data (content). An example would be a submodel for CAD data that is designed for the content "product line".
A submodel has a specific behavior via the content aspect. This is subdivided into the categories temporal development (Progression), access (Access) and extraction (Extraction). Examples for temporal development are different granularities and development states of components or time-dependent validity of part usages (see to structure development Eigner, Stelzer 2009, p. 118 ff.). The user performs the use cases by editing and changing data of the model (authoring). To do this, the submodel must be traversed and a dedicated scope extracted from it (extraction). Typical extraction methods for product models are, for example, configuration by change status or revision, variant or temporal validity.
The system described makes it possible to delimit submodels and define the requirements they must fulfill without reference to IT systems at an abstract level. This creates a neutral basis on which requirements can be recorded and discussed. Submodels can thus be defined step by step to meet the actual requirements without being influenced by previously implemented IT solutions. This reduction allows costs to be saved during implementation, since only those requirements are then implemented that are actually necessary to fulfill the task.
A submodel is technically supported by a data management system (carrier IT system). Carrier systems provide a semantic concept and a behavioral concept based on it (Fig. 3, detail B). Once the submodel has been defined and the carrier system selected, the next step is to implement the submodel, which has so far only been defined in abstract terms, using the concepts provided by the carrier system. This involves fitting the submodel into a semantic framework specified by the carrier system and the behavioral framework based on it. The use cases that are to be fulfilled by the submodel are fulfilled by functions in applications that exploit the semantic framework spanned by the carrier system and the behavioral framework based on it. The carrier system therefore has a direct influence on the feasibility of the requirements of the submodel. Although carrier systems can be adapted to meet requirements more effectively, it must be borne in mind that adaptations can result in semantic inconsistencies, which may mean that some functionalities desired in the future can no longer be used.
The careful planning and execution of the mapping process of the submodels in the carrier system is thus an essential factor of a PLM project that is critical to success and must be supported methodically. The Do(PLM)Con method from Siemens provides the necessary tools for this (see Fischer et al. 2011, p. 20 ff.).
Integration of partial models
In order to cover the integrative use cases required by the various submodels, the submodels must be integrated. Up to now, however, there has been no systematic approach that allows semantic integration to be planned independently of the carrier system. Do(PLM)Con provides such a system. It distinguishes between two essential design areas of submodel integration (cf. Figure 4).
Figure 4: Design areas of submodel integration
The design area "organizational alignment" aims at harmonizing the information-generating processes across the domains involved. Such harmonization is implemented through organizational specifications, which could, for example, stipulate that a design solution may not exist without a corresponding BOM correlate or that the release of a design automatically requires a BOM entry. In order for such an implementation to be successful, it is also necessary to compare the meaning of the information units that will be used together in the future. The meaning alignment of the information units creates the necessary "anchor points" at which the model semantic integration can later start. In the case of an integration scenario of CAx and BOM, the component, the item variant and the item are typically used as jointly used information units via the submodels.
The design area "semantic link architecture" defines the design of the link between the submodels. A connection can be realized either via a so-called "cross-model link" or an "in-model link" (cf. Figure 4, bottom right). A "cross-model link" refers to a link between the objects of the source model and the target model across all submodels, whereas an "in-model link" only links objects within a submodel. When using in-model linking, model extracts of the source model must therefore first be introduced into the target model and persistently stored there. "In-model linking" thus obviously has the disadvantage that it requires redundant data to be kept in both submodels (source and target model). Despite this disadvantage, "in-model linking" is currently the most widely used integration approach. This has a number of reasons, some of which are outlined below.
In current PLM implementations, it is often the case that submodels are implemented in different carrier systems. A "cross model link" then becomes a "cross system link", which is technically demanding and potentially risky. The other reasons are organizational. Different sub-models often show a different development over time (progression). A cross-model link thus bears the risk of losing its content validity over time, resulting in a content inconsistency of the integrated models that has to be corrected manually. In addition, it is often the case, e.g. through simultaneous engineering approaches, that both the source and the target model are worked on at the same time. In this case, the model contents in the source and target models deliberately develop independently of each other, and redundant data that must be maintained twice is therefore necessary for the realization of the business intent.
Such a conception of the integration is not currently carried out within the framework of PLM projects. Often, decisions are made without considering the more precise organizational and technical consequences, which then have to be implemented laboriously and cost-intensively or subsequently corrected. A systematic planning of the design areas of the integration is a decisive factor before the technical realization of the submodels in carrier systems, which can considerably reduce the project risk. In addition, the partial model concept can be used to prospectively analyze and plan the task changes in the development departments that typically accompany the implementation of integrative PLM architectures.
Use of the DoPLMCon for the development of PLM architectures
The conceptual system of the DoPLMCon methodology presented here helps to describe, discuss and develop an integrating PLM architecture consisting of networked submodels on an abstract level. The PLM architecture is designed to be completely independent of the carrier system. Thus, simple and flexible designs of PLM architectures consisting of integrated (sub-)product models can be derived, which enable a harmonious, customer-oriented mix of functional fulfillment, complexity control and performance.
In a second step, implementation alternatives of this PLM architecture are then designed in carrier systems. Do(PLM)Con can then be used to technically validate these implementation alternatives and evaluate them with regard to criteria such as performance, costs, fulfillment of requirements, implementation effort and risks.
Literature
Eigner, Martin; Stelzer, Martin: Product Lifecycle Management. A Guide to Product Development and Life Cycle Management
Heidelberg London New York: Spinger, 2nd edition 2009.
Fischer, Jörg W. et al: Implementing Domain-Integrating PLM Solutions. Do(PLM)Con - an approach to the design and implementation of domain-integrating PLM solutions. In: Industrie Management, Berlin, 27(2011)5, pp. 17-21. (ISSN 1434-1980).
Sendler, Ulrich; Wawer , Volker: From PDM to PLM. Process Optimization through Integration.
Munich: Carl Hanser Verlag, 2011.
