5.4 Integration requirements and constraints

---

5.4.1 Integration needs

For the cases shown in the previous sections, we can conclude that for an efficient development, tight integration of information is needed during the entire development process at all structure levels. All of the different development groups need support for their daily routines, especially during the intensely active development phase. In practice, this means that tight integration with development tools, such as those for mechanical design and graphical viewing and for electrical design and test, are required. It should be observed that information could be provided in very different forms, not only as documentation legible to humans. Information can include CAD/CAM diagrams, lists, and any other type of presentations of components or specification of functional interfaces. Much information is frequently used by different tools, so the interoperability between the tools that are used in the development process is of considerable importance.

The demands of tool and data integration can be a significant obstacle to the use of a specific tool from PDM and SCM in any type of process, or to their simultaneous use. From the efficiency point of view, it would be preferable to use tools dedicated to particular functions in a particular type of process. However, using many tools increases the problem of interoperability between the tools. Even in a specific domain (pure software or pure hardware development), the major problems are related to inadequate interoperability. We can expect even more problems if we use a tool that is a part of one domain in a process that mostly uses tools from another domain.

5.4.2 Overlapping functions and redundant data

In complex software development environments, we can meet two types of redundancy that make the development process difficult, inefficient, and inaccurate. The first type of redundancy is functional redundancy-when two or several functions provide the same or a similar service. Functions may provide the same service on a general level (e.g., generate a status report), but in particular cases they may give different results as they use different types of objects or data or have slightly different behavior. In such a case, functional redundancy is acceptable, although it is preferable for the interfaces and the behaviors of these functions to be the same or at least compatible. If the functions operate on the same or similar data and provide the same service, the redundancy is functionally superfluous and an unnecessary cost. The second type of redundancy is data redundancy, which means that the same data is saved at several places. There are many types of redundancy used to increase the safety of systems (e.g., backup data or dual databases). If the redundancy is incidental and not the goal itself, it might cause many problems. The same data must be updated at all places when it is changed, and if there is no systematic way to do this, the system may enter an inconsistent state with unpredictable consequences. A typical situation of unwanted data redundancy occurs in complex systems with many (independently developed) functions operating on the same data and keeping them in their internal repositories.

Many functions overlap in PDM and SCM. Figure 5.7 depicts the most important functions from both domains. As the figure shows, many functions support the same or similar processes. In the overlap between the two domains are common activities. They are often referred to as a part of CM. However, even for these common activities, different tools and different processes are used. In addition to these overlaps, we must take into consideration other tools that might have redundant functions or use redundant data (e.g., requirements management tools or trouble report tools).

Figure 5.7: Function overlap in PDM and SCM.

5.4.3 Cultural differences

Interoperability is not the only challenge when using PDM and SCM tools. The cultural differences between software and hardware development groups play an important role, which unfortunately often introduces many problems, misunderstandings, and even disregard. Some of the typical problems that occur are:

• Users of both domains believe that the system they use can manage all situations and do not understand the specific requirements of the other domain. Many software developers believe that SCM tools can manage data at the system level as effectively as PDM systems. PDM users, on the other hand, often believe that software consists of binaries only, as easily controlled by a PDM system as any other component. One reason for these beliefs may be the large overlap of functionality and the similar terminology.

• Different terminology is used for the same concepts (e.g., configuration control is the definition and management of product configurations for PDM, as compared with the control of changes to a CI after formal establishment of its configuration documents for SCM).

• The same terminology is used for different behavior. An example is version management, whereby the same terms are used, but the behavior in a PDM context is different from its behavior in an SCM context.

• PDM and SCM users are often located at different departments within the company, and their geographical separation can increase the gap in their understanding of the other group.

These differences increase the difficulties of using tools from the other domain.

5.4.4 Choice between PDM and SCM

The characteristics of the PDM and SCM systems emerge from the nature of the products developed. In the PLC, PDM is focused more on the system design phase, hardware development, and subsequently the production and maintenance/support phase. PDM is less concerned with the software development phase. It is rather the final results of the software development that is controlled by PDM. On the contrary, in the software PLC, the development phase is usually the most intensive part (despite the intention of software engineering to move more activities to the beginning of the PLC). Consequently, the tools bring into focus the support for the corresponding processes.

This means that PDM cannot replace SCM, and SCM cannot provide the functionality provided by PDM. PDM cannot be used for the development of software products, and SCM cannot be used for the development of hardware products.

When developing a product consisting of both hardware and software, the hardware and software subprojects are developed concurrently, and it is particularly advantageous to manage these together. To manage these types of products, we need to have access to all product data in a collected form on system level. For access to all product data in a collected form, we need to have all metadata relating to the product and collected in a single system with connections to all subsystems.

Figure 5.6, in which we can recognize common and parallel ( independent) activities, shows the processes during the PLC. Hardware developers use their development tools in the parallel subprocesses. These tools are more or less tightly integrated with the PDM system, and they send information automatically to PDM. Software developers work in their tools and do not gain any benefits from using the PDM system until the product is ready for integration and verification or customer use. At this point, PDM needs information provided by SCM tools. From a purely functional point of view, the PDM and SCM tools fit together and completely cover the entire PLC, which gives attractive predisposition for their integration. To obtain full support for managing development and product assets (items), we cannot use one of the systems alone. Neither PDM nor SCM can give the full, integrated support required during the entire PLC. We need the functions of both systems.

Hence, for the development of complex products, especially those that consist of both hardware and software parts, the need to use both PDM and SCM tools is evident. Further, it is essential that a seamless integration between these tools is obtained.

---