State of Practice
Historically, PDM and SCM have been two separate domains with their own tools. Following sections describe the basic functionality the two domains and tools consist of.
1 PDM Functionality
PDM systems have been developed to manage large volumes of information created in modern design environments more effectively and to meet demands for faster development of more complex products. PDM is mostly end-user driven, e.g. customers demand their vendors to introduce certain functionality.
One definition of PDM among a number of different definitions with the same meaning is:
PDM is the discipline of controlling the evolution of a product and providing other procedures and tools with the accurate product information at the right time in the right format during the entire product life cycle.
PDM is supporting processes, such as development, manufacturing, marketing, sales, purchasing, and extended enterprises. Even though much of the information in the PDM system is created during the design, other people with different roles use and create information during other phases. In the context of today’s PDM vision, a PDM system is more accurately described as an information infrastructure providing users with support in performing their tasks by means of the different functional models that it incorporates and by means of the other integrated software systems.
1.1 Basic Functionality
The functionality of PDM systems is often divided into two categories: user functions and utility functions. Different types of users may work with different subset of these functions. A user may be a consumer (viewing information) or a producer (creating information).
User functions can be divided into five categories:
• Data vault and document management;
• Workflow and process management;
• Product structure management;
• Classification management;
• Program management.
Utility functions provide an interface between different operating environments and encapsulate their complexity to the users. Utility functions can be divided into five categories:
• Communications and notification;
• Data transport and translation;
• Image services;
• Application integration.
1.1.1 Data vault and document management
PDM systems contains of central locations, vaults, used in the control of all types of product information. Data vaults are either physical locations in the file system (any kind of folder or directory) or databases. Two types of data are stored in data vaults; (i) product data generated by various applications stored in the database or in the file system, and (ii) metadata which describes properties of the product data. Users have access authorities to one or several data vaults, where they can check in documents and control the alteration of the document. To modify a data item, the user checks out to a local work location – a personal physical file location. Any change to the document here will not be visible to other users until it has been checked in again. Check-in and check-out functions provide secure storage and access control to data stored in the data vaults. All members of the project team are provided with access to the work in process (WIP) vault, the vault for the not released information, see figure 1. When the document has passed the approval process, it will be submitted and stored in the release vault, a file location where the users have only read access. The approval process automatically stores information in the release vault to which only the PDM system has write access.
Figure 1 Example of data vault usage
The main objectives for document management functions in PDM systems are such as to provide a structure for storage, selection, and retrieval of information.
1.1.2 Workflow and process management
Workflow management is a critical part in the product definition life cycle to ensure that the right information is available to the correct users at the proper time. It includes defining the steps in the process, the rules and activities associated with the steps, the rules for approval of each step, and the assignment of users to provide approval support. PDM workflow management provides the mechanisms for modeling and managing defined processes automatically. See figure 2 for an example of a workflow for change approval.
Figure 2 Example of a workflow for change approval
1.1.3 Product structure management
When designing a complex product, the management of its component part is as important as the management of the documents that describes the product. A product structure comprises components, the externally visible properties of those components, and the relationships between them. A product structure most often forms a hierarchy of assemblies and components. An assembly consists of other assemblies and/or components. A component is the lowest level of the structure. The product structures are used by different kinds of people, designers to “fill” the structure with the design itself, the purchaser to identify components to purchase, and the manufacturing to collect all objects and information for building the final product. Manufacturing is using the bill of material (BOM). See figure 3 for an example of a quantitative BOM of a bicycle.
Figure 3 Quantitative BOM of a bicycle
1.1.4 Classification management
Classification management is the classification of standard components in a uniform way. To support reuse of standard components, the components are classified and information about them is stored in the PDM system as common attributes. These attributes are used for querying and retrieval of standard components, items, or objects.
1.1.5 Program management
The support for project management provided by PDM systems involves standard functions such as definition of work breakdown structures, resource allocation, and project tracking. Today, most PDM systems are integrated with specialized project management tools. Effective support is then provided with the possibility of relating product and project data with each other.
1.1.6 Communications and notification
As part of the implementation of workflow support, notifications can be automatically sent to the users. Each user can decide to which types of notification he or she wishes to subscribe. Electronic mail is often used as the medium for notification.
22.214.171.124 Data transport and translation
In a PDM system, predefined translators can e used for converting data from one application for use in another and for displaying information. Events can trigger automatic data translation from one application format to another.
1.1.8 Image services
Images can be stored and accessed as any other data in the PDM systems. Visualization tools can be integrated with the PDM system to support collaborative work by making it possible for all users to view images independently if the user has the original tool from where the information was generated.
1.1.9 System Administration
System administration is more complicated and contains more tasks for PDM systems than for other computer systems. The system administration functions include installation and maintenance, role management, workflow definition, operational parameters, system performance monitoring, database and network configuration, access and change permissions, user authorizations, setting up new projects and authorization of project team members, approval procedures, data backup and security, database migrations to later versions, customization, and data archival.
1.1.10 Application integration
Integrations range from the less complex, such as that with text editors, to tight integrations as with computer-aided design (CAD)/computer-aided manufacturing (CAM) and Enterprise resource planning (ERP) systems. These more complex and tight integrations is often the most difficult to achieve.
1.2 Information architecture
1.2.1 Data representation
The information in a PDM system is structured to follow an object-oriented product information model. Objects are two different kinds: business items and data items. Objects used to represent parts, assemblies, and documents are designated business items. A business item contains attributes and metadata, which define the properties of the item. An attribute has a name and one or several values. A PDM system also manages files. A file is represented in the database as a data item. The metadata is separated from the content or actual data (file). This is to enable replication of metadata without necessarily replicating the file. A data item can be reused from several business items. A business item can have a relationship with several data items, not supported in a standard file system. Figure 4 illustrates the data representation of documents. The Cylinder consists of two different documents, the CAD model and the specification, represented by a business item each with different metadata. The actual document or file is represented by the data item and is related to the business item, e.g. the Specification Large can have the file Spec_can.doc related to it.
Figure 5.Figure 4. Data Representation of documents
126.96.36.199 Information model
A database system implements an information model. The PDM information model describes the types of objects, relationships, and relationships between them. This information model can be changed to better suit the needs of a particular business solution in a company.
188.8.131.52 Version management
In PDM systems, the versions of business items are called revisions and are organized in sequential series see figure 5. The business item contains metadata, denoted attributes. PDM supports customized attributes. Major changes of business items are tracked by revisions manually transformed by the user. Different revisions of a business item are connected by a relationship, the revision-of relationship. A PDM system may contain many other relationships, which may have one or more attributes. If a data item is changed, it may be checked in and out several times without creating a new revision. Versions are used to manage the sequence of data items but are usually not visible to the users. Only one user at a time can update a file, i.e. there is no support for concurrent engineering.
Figure 5. Version Management in PDM
3.1.3 System architecture
Figure 6 depicts a PDMM system containing both a metadata database and data items managed by the system but stored in an ordinary file system.
Figure 6. A PDM system with data vaults
184.108.40.206 PDM database
A PDM system uses a database to store data in a structured way. A database offers a query language, which is used to make queries to the database to extract information. As shown in figure 6, a PDM system manages metadata and file data, where the metadata is stored in the database, and file data is stored in the PDM-controlled file locations. Metadata is used to support functions, such as search for information.
220.127.116.11 Data replication in a distributed environment
In the PDM system only metadata or metadata and the files are replicated to other sites as illustrated in figure 7.
A typical PDM tool has a master server, often denoted corporate server. This server contains common information such as access rights for other servers, and locations of them in the network. Irrespective of where in the network the file is located, it is locked when it is updated. A distributed lock mechanism controlled by the master server prevents the check-out of a file by two users at the same time. Such solution does not permit full parallel development, a strategy commonly used in software development.
Figure 7.Figure 7 Server replication in a typical PDM environment.
2 SCM Functionality
SCM is a software engineering discipline for the control and management of the control and the synchronization of the work of the different developers engaged in a project. SCM provides support during the entire development life cycle of a product. Although SCM is of use in all phases of a product life cycle, most SCM activities are concentrated during the development phase, when the program code is actually produced. SCM is designed for use in software development, and it mainly supports functions required specifically by software.
The definition of SCM is:
Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team. 
2.3 Basic Functions
2.3.1 Version Management
Versions in SCM form a graphical structure (see Figure 8).
Figure 6.Figure 8 Version management in SCM
SCM provides support for concurrent engineering: several versions of a file can be developed simultaneously in branches, which may be merged together again if needed. Each time a file is checked out and in, a new version is created. This corresponds to a version in PDM. In SCM, however, versions are visible to the users and are used frequently. A version of a file can be marked with attributes. Versions are often marked using a special attribute called tag or label. Labels almost correspond to revisions in PDM. In SCM there is no support for relationships. Because software developers usually work on the same file at the same time, the branch and merge mechanism is very important.
2.3.2 Workspace Management
Workspace management makes it possible for developers to work transparently with respect to SCM. When developers are focused on solving particular problems and have less interest in administrative tasks, a workspace functions as a sandbox in which they can work in isolation, remaining under the control of the SCM tool. Versions of files are checked out and temporarily stored in the workspace, with a mapping remaining between the versioned objects in the repository and the user files and directories in the workspace. Often all files needed in the build or test procedures are checked out. Thus, the workspace also makes it possible for the checked out in to the common repository to maintain a certain degree of quality. When several developers are working concurrently in their private workspaces, control is needed between the different copies of the same object.
2.3.3 Configuration Selection
A file can include a number of versions, and the one that should be used in a given situation is not always obvious. In every-day work during development, a developer usually wishes to have latest revisions of the files being changed from a particular branch. For other unchanged files, the developer typically wants an older, stable version. A set of particular file versions, particular versions of Configuration Items (CIs), is designated a configuration.
2.3.4 Build Management
Build management supports the user in building the product or part of the product. Build tools such as Make  are used to create the product automatically. The correct files are first collected for a particular build, and are then compiled and linked in the correct order. Make describes the dependencies between source code files at build time and ensures that the dependent source code is built in the correct order.
2.3.5 Concurrent Development
One major advantage of using a SCM system it that it enables teams to work concurrently on a single object. Different developers may be working concurrently on the same files, correcting different errors, or one developer may be working in the latest release while another is correcting an error in a previous release. The SCM system makes this possible by providing a selection of versions building specific configurations for different needs, and a model for synchronization of concurrent changes.
2.3.6 Distributed Development
The SCM environment replicates the total file including the metadata. SCM tools, the servers replicate data between two nodes, using a peer-to-peer protocol. Any structures of servers can be built by connecting servers to each other. An example with four servers is depicted in figure 9. These examples show that the PDM mechanism is not appropriate for distributed software development. Similar is valid for SCM tools: in cases in which metadata is more often manipulated the SCM solution is not the most appropriate.
Figure 9 Server replication in a typical SCM environment
To be aware of an entire life of a product, we must understand all of the processes involved in the product’s development and operation, and all activities of people involved in the processes. A product’s life cycle model is divided into several life cycle phases. Independent of the product type, we can define six generic phases  (see figure 10): (i) the business idea of the product including assessment of the market and technology, (ii) requirements management phase focuses on further identification of requirements, analyze and specification, (iii) development includes design and implementation of all artefacts needed for production where hardware products consists of documents and prototyping, and software development phase complete with the product itself, (iv) the production phase is completely different for hardware and software products. For a pure software product, this phase is automated to a high degree ad has a low production cost. For a product with hardware elements, this phase is demanding and costly, (v) in the operation and maintenance phase consumers use the product, and the final phase is (vi) the disposal depending on the product.
Generic product lifecycles can be implemented in different ways, differences in the cases of software and hardware products. A generic process from Ulrich and Eppinger  can describe the main steps of pure hardware development. The process contains of six steps (see figure 11 lower part). The (i) detailed requirements management closely connected to the (ii) conceptual development in which product concepts are generated precedes the development phase. At the (iii) system-level design the architecture is decided including sub-systems and components. The components are further designed during the (iv) detailed design. During the development phases the developers are using different tools, e.g. Computer-Aided-Design (CAD) tools for drawings and models. (v) Testing and refinement includes the building of product prototypes to test the product and production system, the most costly part of the phases. During (vi) production ramp up, the production system is used for serial production of the product, beginning at a low rate but then increasing to full production.
The software development process consists of similar phases  see figure 11 upper part. The model includes the phases: (i) requirements analyze documented in a requirement specification used as an input to (ii) overall design where the system architecture is designed, components and their interfaces identified and to the detailed design where component implementations are specified. In the (iii) implementation phase, developers follow the design documentation and implement the system. During the development phase, the developers are using different tools such as compilers, linkers, and SCM systems for managing the amount of files and versions. In the (iv) integration and test phase the integrators build the systems from components and tested. During this phase the SCM system is useful for building the system. The final phase is release where the product is packaged in an appropriated form for delivery and installation all done by the developers. There are many different models that define different software processes, e.g. the Unified Process  which is divided into a number of incremental stages in which the product is built progressively
Figure 11: Software and hardware development processes
4 People and Cultural behaviours
The cultural differences between hardware and software development groups play a much more important role than visible when building integration between PDM and SCM. First of all, both domains are huge using completely different tools. Secondly, users from the different domains do not have knowledge about the other domain. Low communication between the domains causes poor understanding of each other’s problems and requirements. Thirdly, users from both domains believe that the system they use can manage all situations from the other domain , . Fourthly, PDM and SCM users are often located at different departments within the company. Their geographical separation can increase the gap in their understanding of the other group. Fifthly, the hardware designer uses a lot of documents to describe the product. These documents are transferred to the production and manufacturing part used of another person to produce the actual product. Hence, the hardware designer focuses on documents. The software designer writes a lot of source code. The designer then generates the actual product, the load modules, with no other person involved. Hence, the software designers focus on source code more than documents and have small understanding of the importance of writing documents.
Standards and de facto standards vary considerably, in their scope, in their purpose, in the formality of their acceptance, their use, etc. With respect to PDM and SCM systems we can classify standards as those used for information exchange in its broadest meaning, or standards, which specify processes in particular, domains. Further, there are standards, which are applicable to SCM only or to PDM only, or standards, which are valid for both PDM and SCM and, in many cases, for other domains. Several CM standards were acquired by SCM. Finally, there are standards which can be directly implemented by software (typically the implementation of particular protocols or the management of particular data formats), and standards which involve human activities and can possibly be supported, but not automated, by tools (usually process-related standards).
PDM and SCM systems usually consist of several tools that exchange data. As these tools have neither common data nor a common information model and exchange of information is one of the major problems in their use.
For PDM there exist standards as ISO 10300 STEP , and relating standards as ANSI/EIA-649  Non-consensus Standards for CM. Although PDM uses many standards, there are no standards that are exclusively intended for PDM systems. Many standards are closely related to PDM and originate from PDM-related requirements.
No explicit standards exist for SCM except related standards for CM such as ISO 10007 Guide Line for Configuration Management , IEEE STD 1042—1987 Guide to Software Configuration Management  and IEEE STD 828-1998 Standard for Software Configuration Management Plans .
There are different standards and models for different Product Life Cycle Management (PLCs). Some standards addresses the life cycles of systems closely related to PDM and SCM, e.g. ISO/IEC FDIS 15288 Systems Engineering – System Life Cycle Processes .
For integration purposes no standards exist today.
5 Key Players
The PDM domain from a tool perspective is divided into several sub-domains depending on type of industry. Some vendors divide the end-users into areas where the companies are situated, such as Aerospace and Defense, Automotive Supplier, Consumer and Packaged products, and High tech Electronics. The key industrial players are different depending on sub-domain, e.g. key industrial player in car-manufacturing industry is Ford, in Aerospace and Defense the aircraft manufacturers Boeing, Lockheed Martin, and BAE Systems. In the High tech Electronics sub-domain key players are such as Ericsson AB , Motorola , OKI Electric , and Seagate . The market leading tools are such as Teamcenter , Matrix PLM Platform , Enovia Solutions , and Windchill PDMLink .
Key industrial players in the SCM areas are telecom industry and other companies developing and selling software products or complex products.
The SCM tools list is increasing rapidly. More than 50 commercial tools exist, such as AllFusion Harvest Change Manager , IBM Rational ClearCase , CM Synergy , Serena Dimensions, Serena Professional , and Microsoft Visual Source Safe . In addition to commercial tools, there are a large number of free SCM tools. It is interesting to note that two SCM tools dominate in free software market: RCS , and CVS .
Since the border between hardware and software development are vanishing, car-manufactures, aircraft manufacturers, and telecom sees the benefit from integrating both areas and tools. Key players from the industry in integrating PDM and SCM are Ericsson AB, and Motorola.