Chapter 6: PDM and SCM Integration

---

The whole is more than the sum of its parts. —Aristotle, Metaphysica

The purpose of PDM and SCM tools is to provide an infrastructure and support for many activities during a PLC. Many other tools are available that provide services with the same purpose, but these are most often focused on one particular activity in the life cycle. From the stakeholders’ point of view (i.e., from the perspective of developers, managers, and salesmen), it is important that the use of many different tools does not introduce new complexity into the entire process and that the information and services must be accessible in a smooth and uniform way. For this reason, integration issues are a very important factor for the successful and efficient utilization of these tools, and not only for PDM and SCM. Most PDM and SCM tools provide a certain support for integration. As we saw in Chapter 4, there is a tendency for other tools to be integrated into PDM tools, whereas SCM tools are often used as components in other tools (e.g., in integrated development environments). In this chapter, we shall concentrate on an analysis of the integration of PDM and SCM. This integration might be complicated, as PDM and SCM cover many activities in the PLC and provide support using similar, but not necessarily identical, data and process models. We shall first analyze integration alternatives, then consider several scenarios in which PMD or SCM tools are used in an integrated environment, and finally show two cases of integration of commercial PDM and SCM tools.

6.1 Possible integrations

In general, there are three possibilities for achieving PDM and SCM interoperability:

• By obtaining a full integration of PDM and SCM tools, developing a common package with all functions using the same common structures and data, common user interfaces, and common APIs.

• By obtaining a loose integration in which each tool has its own functions, independent of the other, but in which there are mechanisms for exchanging information and providing services automatically without additional effort by the users.

• By obtaining no integration, but by using certain import/export functions; in this case, manual procedures, which enable information exchange, must be identified and introduced in the processes of the PLC.

6.1.1 Full integration

Figure 6.1 shows an ideal full integration model, which includes APIs of PDM, SCM, and other engineering tools, which provide a common information model and a common user interface, transparent to the tools. The tools are integrated in a common layered architecture; the layers are not encapsulated within particular tools, but common to all functions. The lowest layer is a repository (data) layer, which includes repositories such as databases and file systems and a common information model that defines the internal data structures, such as product and project structures, configurations, and versions. The middle layer includes business logic and consists of different tools providing different services. The tools use a standardized API for connection to the common information model. The business layer is connected to the upper layer via the common user interface using standardized API in a similar way. The main function of the upper layer, human application interaction, is as far as possible independent of particular tools. Recent technologies, in particular Web- and Internet-based technologies, make it possible to achieve the desired uniformity.

Figure 6.1: PDM and SCM integration—Common API and common repositories.

This model enables easy integration of new tools and functions that use standardized data types and standardized API. ^[1]

Unfortunately, it is difficult to implement this model using the tools available on the market today. The tools have their own specific API, and the functionality of many of these APIs does not completely match the functionality of the tool. The repository layers are tightly integrated with the business layers, and it is therefore impossible to build a common repository using the repositories of the tools. PDM and SCM may have the same basic type of repository (e.g., a relational database and a file system), but without a common information model, the level of abstraction is too low to be appropriate for integration. The main disadvantage of this model is the lack of a standardized information model. For the same reason, the interoperability of PDM and SCM tools with other engineering tools is not easily achieved. Despite these difficulties, work is in progress to obtain full integration of different engineering tools in some PDM systems. In such cases, the PDM tool consists of a larger number of different functions integrated directly in PDM or added as options to the basic package. The weakness of this approach is the proprietary nature of the information model, which is not readily acceptable to other PDM tool vendors. This increases the difficulty of developing and maintaining new tools. The PDM system is expanding and becoming increasingly expensive and complex.

6.1.2 Loose integration

In a loose integration, the tools operate more independently of each other and store data in their own repository. Although their repositories may be of the same type for different tools (e.g., relational database), the information models are different and accessible only from the particular tools. Different layers are visible within the particular tools. Information is exchanged through additional interoperability functions, which may be either separate applications or functions integrated within the PDM or SCM tools. The interoperability functions communicate with these tools either via their APIs on the service level or directly on the data level. The data exchange may be started in different ways—triggered from specific tools or initiated by the users. Loose integration system architecture is shown in Figure 6.2. The figure does not show integration with other tools, but the same principle applies as for PDM and SCM.

Figure 6.2: PDM and SCM loose integration.

The main advantage of this approach is the omission of the requirement of a common information model, which makes it more possible to use existing tools. Instead of using a common information model (experience has shown that it is extremely difficult to agree on a common information model), it is sufficient to have a common data model (i.e., structure specification on a lower level and conversion rules between different data types). The main disadvantage is the necessity to build additional interoperability functions. Each addition of a new tool will require the development of new interoperability functions between the new tool and other tools. It may also require changes in existing functions. The number of interoperability functions may increase very quickly and it is not clear who is to be responsible for developing these functions, the PDM vendors, the SCM vendors, or the customers themselves.

Because data is encapsulated within particular tools in a loose integration, it may happen that the same information is stored in several places. This means that there will always be a risk that data in only one of the several repositories is updated, thereby introducing an inconsistent state. To avoid such an inconsistency, synchronization of the tools and monitoring of the repositories to detect inconsistency must be performed periodically or on an interrupt/trigger basis.

Another aspect of this problem is that there may be constraints on the workflow between tools, because while it may be possible to synchronize changes in tool A with tool B, the reverse may not be true. The problem arises when changes in a downstream process (in tool B) demand changes in an upstream process (in tool A). It may not be logically possible for the downstream process to create data to automatically populate the upstream process. A relationship between requirements management tools and software development environments is an example.

6.1.2.1 Loose integration and the component-based approach

As different tools provide different APIs, new interoperability functions must be built for every new tool introduced, for both the business and the communication parts. Modern development technologies based on component-based development [1] make use of mechanisms that provide support for many standard functions, such as communication between the components (often designated as middleware) or integration of components in distributed applications. When using these technologies (e.g., CORBA, COM/DCOM, .NET, and JavaBeans), development efforts can be significantly reduced, with the interoperability functions including only the business logic while all of the other parts required for the operation are added automatically. Modern tools including SCM and PDM tools use these technologies today. Figure 6.3 shows the architecture of a loose integration that uses a middleware facility.

Figure 6.3: A loose integration using middleware technology.

6.1.2.2 PDM-centric integration

As PDM covers a larger part of the total PLC and as PDM deals with metadata (i.e., description and structuring of data), it is natural that, as far as possible, communication with the user is via PDM. However, there will remain tools and users that interact directly with SCM tools. SCM tools can be integrated with PDM tools in the same way that they are integrated with other engineering tools (such as IDE tools); PDM tools use the API from SCM. Users communicate only via PDM, which is responsible for updating information for both PDM and SCM data. This model provides better control of the consistency of duplicated data. However, similar problems remain. For example, there are many existing integrations of different development tools with SCM tools, and it is unrealistic to assume that such integrations will not be used independently of the PDM integration.

6.1.2.3 Integration points

The complexity of managing system consistency depends on the development process, which identifies data and stages in the process in which data is exchanged or copied (see Figure 5.6). For this reason, it is important to identify these stages. The fewer the number of these points and the less the frequency of information exchange, the simpler the model will be—but the benefits of the integration will be lower.

The freezing of a product version is an important integration point in the development process, and the minimal data integration then required is on the product version and configuration level. As PDM does not provide support for the branching and merging that is important in software development, it is suitable for software file versioning to be under the control of the SCM tool. From a PDM point of view, it is more interesting to keep information about specific versions of files, but not all versions of files, created in the software development process collected in a specific configuration or in a baseline. This means that a list of files of a baseline containing the pointers to the actual files can be saved in the PDM system, as shown in Figure 6.4.

Figure 6.4: Example of integration of software items.

6.1.3 No integration

If no integration is obtained between the tools, manual intervention is required, and there is a great risk of inconsistencies being introduced into the system. It is therefore important to precisely identify and describe the manual routines for data updating and to strictly follow these routines. The routines will typically include import/export functions between the systems.

6.1.4 Conclusion

For many good reasons, the integration of PDM and SCM is advantageous. In practice, there exist many problems. First, the integration requires the sharing or exchange of data between different tools from the same domain (PDM or SCM) but from different phases. Neither PDM nor SCM has yet solved this problem completely. A more serious problem arises when data must be shared or exchanged between tools from these two domains. The second problem is the choice of the tools and methods from the overlapping areas. Even if a particular tool provides excellent support within one domain, that does not mean that it is suitable or well integrated within the other.

To achieve a full integration of PDM and SCM, we must define and implement a common product model, common evolution model, and common process model as described in [2]. A common support for the process model can be used with the present tools to some extent, but other models with today’s functionality differ too much to be of use as common models. A full integration would require enormous efforts from PDM and SCM vendors and from users of the existing tools. It is not likely that the vendors can or wish to take this step.

We can conclude that the realistic solution for system integration is a loose integration, with relatively independent tools and well-defined interfaces between them. To obtain an efficient and useful integration we must have:

• APIs of PDM and SCM tools;

• Easy-to-use and accurate interoperability functions between PDM and SCM;

• Synchronization monitors, which can resolve inconsistency between the systems;

• The possibility of using PDM and SCM tools directly without running into an inconsistent state.

^[1]Implementation of new tools might be somewhat more complex because the tools must conform to the standards of the common information model. On the other hand, when standards are used, the development of tools using these standards may be facilitated by different development tools, which automatically generate standard parts of the tools.

---