The invention relates to a product data exchange system for exchanging technical product data between respective computer systems of a plurality of collaborating companies. The invention further relates to a method of exchanging technical product data between the collaborating companies.
Many product supplying companies operate in a global network with customers, co-developers, suppliers, contract manufacturers, subcontractors, service companies, etc. Each of those companies may again have co-developers, suppliers, subcontractors, etc. For example, production and servicing of a consumer electronics device may involve several companies for:
During the lifecycle of a product, the availability of the corresponding technical product data in the right versions, on the right location, to the right person, and in the right format is essential for the business. Internally, most companies use various data management systems to manage product data and the related processes to distribute this information across their own development and manufacturing sites. Examples of such systems are Computer Aided Design/Engineering (CAD/CAE/CASE) systems (e.g. Unigraphics, Pro/Engineer, AutoCAD, Catia, Mentor Graphics, Cadence, Ansys, Continuus, Telelogic Synergy and ClearCase); Product Data Management/Product Lifecycle Management (PDM/PLM) systems (e.g. Metaphase, EDS TeamCenter, eMatrix, PTC WindChill, SAP/PLM, IBM Dassault Enovia); and Enterprise Resource Planning/Customer Relationship Management/Component- and Supplier Management/Supply Chain Management (ERP/CRM/CSM/SCM) systems (e.g. BaaN, SAP, PeopleSoft, Aspect). However, to facilitate the collaborative development and supply chain communication with external partners (and sometimes also internal partners), the distribution and exchange of technical product data is needed. The technical product data preferably includes all technical disciplines (e.g. software, mechanics, electronics) and covers the entire product lifecycle (i.e. from conceptual design to product obsolescence). For the exchange of operational data between companies (e.g. pricing, ordering, invoicing and payment information) e-commerce and b2b-commerce standards have been developed.
For the exchange of technical product data the Nemi/IPC Product Data eXchange (PDX) standard for electronics manufacturing supply chain communication, IPC-257-Series, have been developed by the Nemi (National Electronics Manufacturing Initiative, www.nemi.org) and IPC (Association Connecting Electronic Industries, www.ipc.org). This standard focuses on the manufacturing supply chain communication between Original Equipment Manufacturers, Electronics Manufacturing Services and component suppliers in the electronics field. The standard is intended for direct data exchange between data management systems that comply with the standard (a distributed approach). No provisions exist for use of non-compliant systems or no system at all.
A centralized approach is known from the SAP Collaborative Engineering and Project management application (CEP) designed to facilitate engineering and project management efforts of dispersed groups. CEP is a collaborative environment in which the responsible company (initiator) collects project relevant information, using the SAP-backbone and publishes the information for access by business partners. It gives the partners via a web-browser (on-line) access to the project info stored in the CEP application. By means of a web-browser the partners can log-in to the CEP system, view and retrieve the information that has been published for them by the initiator to them. For downloading the assigned information, participants select a folder and download its contents to their local PC. The CEP work area allows navigation and access to folder information such as bills of material, project plans and related documents. Partners can make off-line modifications to the downloaded information and upload the configuration folder with the modifications to the ITS server of the owner. At the initiator (owner) site there exist a tight integration of the CEP environment into owner's SAP suite of change and lifecycle management applications. The data structures and working methods in CEP are based on the SAP system of the owner. The CEP system allows external partner to work in (a part of) the owner's SAP system. It provides no solution to couple other systems (or other SAP databases) to the SAP system of the owner, or to facilitate data exchange between multiple systems. The CEP system thus forces partners to work with data structures and working methods of SAP system of the owner. This is problematic because the data structures and working methods will not match with the partners' own PDM environments.
It is an object of the invention to provide a system and method for exchanging technical product data that is more open.
To meet the object of the invention, at least a computer system of a first one of the collaborating companies includes:
a plurality of distinct data management systems, such as CAD, PLM, ERP, each for creating respective technical product data; and
an editing system for:
The editing system enables a company to keep on using distinct data management systems and combine all relevant technical product data into one exchange package and provide that package to the partners. The data management systems need not be of one make and also need not to comply with one standard. Optimized data management systems may be used. The data management systems may, for example, be optimized for the task (e.g. design mechanical parts or design of software) or optimized in price/performance/functionality for the company (e.g. a full-blown distributed system for multinationals and a simple stand-alone system for a small company in a developing country). The data management system may even be proprietary. The exchange package may be provided in any suitable way. In general, the package may be relatively large, for example between 1 and 500 Mbytes large, since some technical data files (e.g. CAD files) by nature are large. The package is, therefore, preferably provided using off-line electronic file transfer or on a record carrier, such as a CD-ROM. The package is transferred in its entirety. The elements of the package need not to be selected and downloaded individually, in an on-line manner.
According to the measure of the dependent claim 2, a computer system of at least one of the collaborating companies includes:
a further data management system for operating on technical product data; and
a second editing system for:
In this way, the company that receives the package can keep on using its own data management system. The editor enables a user to retrieve those parts of the package that are relevant for the company and can be imported by its data management system.
According to the measure of the dependent claim 3, a computer system of at least one of the collaborating companies includes a third editing system for:
retrieving the exchange package;
combining user-selectable parts of technical product data in the retrieved exchange package into a further exchange package; and
providing the further exchange package to a computer system located at at least one sub-contractor of the collaborating company.
In this way, a ‘hierarchy’ of collaborating companies can be formed. For example, a supplier of a module may outsource development/supply of parts of the module. The editor enables a company to select only those parts relevant for its suppliers.
According to the measure of the dependent claim 4, the editing system enables a user to perform at least one of the following operations:
According to the measure of the dependent claim 5, the editing system is operative to automatically insert traceability data into the exchange package representative of control operations of a user of the system. Since the user of the editing system selects data from different sources, the user as such adds knowledge. The operations of the user are recorded in the package, so that at a later moment it can be established why certain data is or is not in the package.
According to the measure of the dependent claim 6, the traceability data includes:
According to the measure of the dependent claim 7, the editing system is operative to import technical product data that relates to a same baseline of the project from the plurality of the data management systems. In this context with baseline is meant a consistent and complete set of technical product data, relating to a same version/revision of the data, that the receiving company needs to perform a task that has been assigned to him. Preferably, the exchange package exclusively contains data relating to one baseline to avoid that a receiver of the package gets confused on what which version/revision is the proper one to use. The baseline approach also limits the number of times that product data has to be exchanged during a certain collaboration activity, since an updated version of a file is not exchanged as no new overall baseline status has been reached. It also avoids the risk that a company works on documents from different partners that, although in itself correct, actually should not be used in combination, since they relate to different versions and may be incompatible.
According to the measure of the dependent claim 8, a computer system of at least one of the collaborating companies includes a fourth editing system for:
retrieving the exchange package;
adding problem reporting data relating to at least one entity of the technical product data in the retrieved exchange package, forming an extended exchange package; and
providing the extended exchange package to at least one computer system of a collaborating company.
In this way, problem reporting data is incorporated into the same package enabling partners to observe that a problem has been reported and to which entity it relates.
According to the measure of the dependent claim 9, the editing system is operative to incorporate the representation of the added technical product data and/or modified and/or removed technical product data in the form of a delta description that covers changes with respect to technical product data elements in a previously exchanged exchange package. In particular if the changes are small, this will keep the size increase due to the change limited. Partners can more easily spot the change, while by applying the change to a full previous version in the package they can still easily retrieve the full updated version.
According to the measure of the dependent claim 10, the data exchange package includes a header and optional attachments for representing technical product data in a data management system specific format, such as a specific CAD format. For example, CAD resource files, software designs, circuit board layouts, etc. may all be attached in the format as used by the partners involved in that aspect. Clearly, a conversion may be required if partners involved in a same aspect (e.g. designing a mechanical part using a CAD system and manufacturing the part using a CAM system) do not using the same internal format. In practice, such partners can usually agree on a commonly supported format that one system can export and the other system can import. In the system according to the invention, the technical product data in the agreed common format can be included in the exchange package as attachments. The editing system need not, but may be able to, fully interpret the format. If so desired, the editing system may perform import/export conversion where no common format can be agreed between partners.
According to the measure of the dependent claim 11, the technical product data in the exchange package is arranged in a plurality of entities, and the exchange package includes for each of the entities information on one of the collaborating companies that has ownership of the entity; the editing system being operative to, under control of a user, trigger transfer of the ownership for a user-selectable entity in the exchange package to another one of the collaborating companies. In this way responsibility can change between companies without any need for a full copying of product management system from one company to another. Such a transfer may, for example, occur during the life cycle of a product, e.g. responsibility is passed on from a manufacturing company to a service company. A transfer may also occur when a company divests its interest in a product to another company. Ownership can be separately transferred for each entity. In this way, different companies can be responsible for different parts and ownership can flexibly transferred (e.g. ownership can temporarily transferred to a sub-contractor). Preferably, transfer of ownership is effected by including in metadata of the header of the exchange package an indication of a current owner, an indication of a desired owner, and an indication of a date of transfer of ownership to the desired owner.
According to the measure of the dependent claim 13, metadata in the header includes status information on sub-projects of the project; and the editing system is operative to convert status information imported from a data management system in a data management specific format to a predetermined format. In this way, the conventional data management systems can keep their own way of indicating status and companies do not need to change the internal way of working, while for a good understanding between the partners a common status is used.
According to the measure of the dependent claim 14, metadata in the header includes information representing a relationship between attachments. Each of the data management system may already have a large number of files, with sometimes complex inherent relationships. Simply copying those files from diverse data managements systems into one package would make the content very difficult to understand for a partner. Therefore, additional information in the package indicates the structure/relationships between the documents.
According to the measure of the dependent claim 15, metadata in the header includes information on a task of the collaborating companies, such as a developer task, manufacturer task, supplier or maintenance task. For projects involving many companies, and in particular involving a hierarchy of several layers of companies, relationships and related responsibilities may be unclear. By explicitly adding task information in the exchange package, such problems are avoided.
According to the measure of the dependent claim 16, the header is in the XML format. This enables a company that does not have a dedicated editor to still observe and retrieve data from the exchange package, for example using a conventional web browser that has opened the package locally.
To meet an object of the invention, an editing system including means for:
importing technical product data relating to a user-selectable project from a plurality of distinct data management systems, such as CAD, PLM, ERP, each for creating respective technical product data;
creating an exchange package representing user-selectable parts of the imported technical product data; and
providing the exchange package to a computer system located at at least one of the other collaborating companies.
To meet an object of the invention, a method of exchanging technical product data between respective computer systems of a plurality of collaborating companies includes:
importing technical product data relating to a user-selectable project from a plurality of distinct data management systems , such as CAD, PLM, ERP, each for creating respective technical product data;
creating an exchange package representing user-selectable parts of the imported technical product data; and
providing the exchange package to a computer system located at at least one of the other collaborating companies.
To meet an object of the invention, a computer program product is operative to cause a processor to execute the steps of the method.
These and other aspects of the invention are apparent from and will be elucidated, by way of a non-limitative example, with reference to the embodiments described hereinafter.
In the drawings:
It will be appreciated that two collaborating companies may in fact be part of a same mother company. For example, a consumer electronics (CE) producing company may be owned by a mother company that also own an IC producing company that is a co-developer and/or supplier to the CE company.
The editing system may be implemented in any suitable way. Typically, it is implemented on conventional computer, such as a PC or workstation, where the functionality of the editing system is performed by the processor (not shown) under control of a suitable program. The program may be loaded form a background storage (not shown), such as a hard disc, or even ROM, into the processor or a working memory, such as the main RAM of the computer. The user can control the editing system 318 via any suitable user interface (not shown), such as a keyboard/mouse for input and a display/printer for output. In particular, in an embodiment, the editing system lets a user to perform at least one of the following control operations:
For example, a user may add technical product data that is not present in the PDM system or can not be exported in a format that can be imported by the editing system 318. A user may remove parts of the technical data, e.g. data that is irrelevant for the collaborating company to which the package is sent. The user may also modify a user-selectable part of the data, e.g. to reflect recent changes not yet effectuated in the PDM system.
In an embodiment of the invention, a computer system 320 of at least one of the collaborating companies includes a further data management system 322 for operating on technical product data. In the example of
In an embodiment according to the invention, a computer system 330 of at least one of the collaborating companies includes a third editing system 338. In the example of
It will be appreciated that user-control of an editing system can be automated. For example, a user may once perform a certain task (e.g. selection of data imported form the PDM systems that needs to be represented in the package) and the editing system may be able to repeat this task at a later moment, similar to recording a macro and executed it again later on. A user may also ‘program’ the user control task into the editing system, e.g. using scripting.
In an embodiment, the data exchange package includes a header and optional attachments for representing technical product data in a data management system specific format, such as a specific CAD format. Preferably, wherein the header is in the XML format. The header may include metadata as will be described in more detail below. Using XML enables a collaborating company to view the package using a conventional internet browser, such as Microsoft's Internet Explorer. This is illustrated for computer system 350 that only includes a browser. With the browser the user of the system can select parts of the package and store and/or print them. The selected parts can thus also be imported in PDM systems. In an embodiment, the package according to the invention is based on an existing, open data exchange standard. In particular, the package may be based on the Nemi/IPC Product Data eXchange (PDX) standard for electronics manufacturing supply chain communication, IPC-257-Series, where additional functionality according to the invention can be achieved by extension to this standard. Certain attributes in an exemplary package definition may be the same as in the IPC-257-Series. Those attributes will not be defined in full here. The attribute definitions of this standard are hereby included by reference.
Baselines and Delta Packages
In an embodiment, a product data exchange package contains a baseline or the set of latest information of the project. A baseline is a consistent set of product information. The various versions and revisions of the technical product data in the baseline are preferably consistent with each other. The package contains only one specific revision or version of technical product data. Multiple revisions or versions of technical product data is preferably not represented in the same package, since it will not be clear to the receiver which revision is the proper one to use. An exception is the use of delta packages, as will be described in more detail below. An issuer of the package (i.e. the user controlling the editing system 318) may issue a same baseline package to all collaborating companies. This may, for example, be useful at the start of a project, where most information in the package is global. The issuer may also issue packages targeted at the recipient, i.e. containing only the selection of the technical project data in the project that is relevant for the recipient. For example, a manufacturer of a specific mechanical part only needs to obtain data relevant for the production of that part.
Once packages with product information have been distributed, the original information at the owning site may change. Preferably, changes are not communicated immediately. Instead, the preferred approach is to collect product information in such a way in the package that the receiver can work with this information without having to know all intermediate changes that the owner made. For example, in a software development process an owner distributes version “0.3” for testing purposes to a partner. In the meantime, the software developer continues his work (and a version “0.4” and “0.5” are created) without distributing these updates to the partner. Finally, after having received the partner's test results and having incorporated these in the software, the owner distributes version “0.6” since this is the next release that is of interest to the partner. Thus, the intermediate steps made by the owner that led from the original information to the new information need not be communicated.
For distributing the changes that have occurred in a period of time, the data exchange system according to the invention supports at least one of the following two approaches:
The concept of delta packages is further illustrated in
Delta packages can be handled using the following attributes on the elements in the package:
Package Structure
Examples of changes are: engineering changes, part list changes. Changes are associated with the affected documents and items. Furthermore, they are associated with the problem reports 644 that they resolve and the party 646 approving the change.
Traditionally, the exchange of source data from multiple design authoring systems (e.g. MCAD, ECAD and CASE tools) between heterogeneous design data management systems (e.g. CAD-PDM databases and file servers) was problematic due to:
This complexity is not addressed in state of the art open product data exchange standards where files are implemented as simple attachments without relations to other attachments. For an effective exchange of technical product data structures, the exchange package incorporates structures in at least one of the following ways:
An example of a package Pckg is illustrated in
Ownership
Product data exchange leads to the situation that copies of technical product data are distributed to multiple locations. It is preferred that it is known where the original master of the information is kept. In an embodiment, the product data exchange package incorporates this information by assigning owners to the main elements in the package. The owner is the person or organization that keeps and maintains the master of distributed product information. Preferably, in the product data exchange package owners are assigned to items, documents, changes and problem reports.
The owner of an item is preferably the owner of all underlying elements including:
The owner of a document is preferably the owner of all underlying elements including:
The owner of a change is preferably the owner of all underlying elements including:
The owner of a problem report is preferably the owner of all underlying elements including the links to affected items (by means of the ‘affected items’ element.)
The ownership information allows that product information from multiple owners is communicated in a single product data exchange package. Preferably, the owner of the information is responsible for the distribution of the changes. This is illustrated in the figure below. Note that during the collaboration with partners the ownership of product information may shift from one site to another. When the ownership shifts, the new owner will also become responsible for distributing the changes that he makes on the information.
During the collaboration with partners the ownership of product information may shift from one site to another. An example scenario is given in the
In an embodiment of the system according to the invention, to communicate the transfer of ownership, the following information is added in the product data exchange package to the items and/or documents that will be transferred in addition to the current information defined in IPC standard:
The date at which the transfer of ownership becomes effective, by means of the attribute ‘transfer owner date’.
By transferring ownership, both partners preferably agree that:
It is desired that the communication of problems (e.g. enhancement requests, field problems) over the development and supply chain is established as early as possible in order to allow all business partners to properly respond, communicate and implement solutions. In an embodiment according to the invention, problem reports can be created and incorporated in the exchange package. Preferably, everyone in the chain can create a problem report. The creator of the problem report is called the problem originator. The originator is not necessary the ‘problem owner’. Depending on the cooperation model between the partners, it may be decided to whom the originator shall address the problem reports. For example, problem reports may be collected and managed centrally by the OEM, or a distributed model may be agreed in which problem reports are submitted directly to the respective owner of the affected modules. The person or organisation that is assigned to solve the problem will become the problem owner. The problem owner is responsible for handling the problem. Furthermore, the problem owner is responsible for communicating the problem resolution and status to the partners. This is further illustrated in
Problem reports in the exchange package can be handled by defining an entity ‘ProblemReport’. The following table specifies the possible attributes for an embodiment of the ‘Problem Report’ entity in an open product data exchange standard:
The ‘AffectedItems’ and ‘AffectedItem’ elements are used to relate the ProblemReport to Items.
Process Status
In an embodiment according to the invention, the system supports that the partners using product data exchange in their collaborative development and supply chain communication can follow their own internal processes. This is also illustrated in the
Furthermore, the status of a (sub-)project, indicating the status of an activity at the owner's site, may be represented in the package in a similar way. The predetermined list of states has a defined same meaning for all collaborating companies. In an embodiment, the editing system is able to convert internal states (e.g. defined by a PDM system or defined within one of the collaborating companies) to the predetermined states. To this end, a user may define a conversion table in the editing systems so that the editing system can perform the conversion automatically. Since a conversion may not be perfect, preferably the editing system at a receiving site makes status information from the owner visible by means of an additional field. This field may also be exported to the PDM system in addition to the local state information. In most cases, it won't make sense to map the status information from the sender to the lifecycle process of the receiver because sender and receiver will follow different processes.
Task Information
In an embodiment, the tasks that have to be executed with distributed product data are communicated in the product data exchange package. The purpose of communicating this information is that every partner can be informed on the responsibilities of the other partners. The task information can be used for:
The following four different types of tasks may be distinguished:
A preferred way of exchanging task information is the following:
By means of the owner information, the receiver of the package will be able to locate the responsible party for the information.
In an embodiment of the invention, task information is incorporated into the package using the ‘ApprovedManufacturerList’ and ‘ApprovedSupplierList’ elements from the IPC-2578 standard and adding:
And defining an additional attribute ‘taskInstructions’.
Details of a Delta Package
The delta package may contain all modified Items, Documents, Changes, ProblemReports, and their underlying elements, depending entities (e.g. task information) and attributes. Note that if only a single attribute field of, for example, an Item has changed, then the complete Item element with all underlying elements and attributes will be exchanged in the delta package.
A delta package can be created by defining a new entity ‘Delta’. The Delta entity has two underlying elements: ‘DeltaNew’ and ‘DeltaOld’. A ‘DeltaNew’ element contains the changed Items, Documents, Changes, etc. The receiver can use these elements to update previously received information. A ‘DeltaOld’ element contains the original Items, Documents, Changes, etc. that have in the meantime been changed. For exchanging delta packages, this element is optional. (Since the receiver will already have this information.) The main purpose of the element is for traceability, which is described in more detail below.
The table below specifies possible attributes of the ‘DeltaOld’ and ‘DeltaNew’ elements for an embodiment in an open product data exchange standard:
Traceability
As product content moves through the extended enterprise, the control over changes in information due to manual update processes may be lost. Issues that must be addressed are:
In certain environments and under certain co-operation models it may be required that all changes must be traceable. To meet traceability requirements, it is preferred to keep track of the following information:
The traceability information can be used in the following ways:
The traceability data includes:
This can be done by using the ‘Delta’ elements that have been described above. When an item, document, change, problem report, contact, manufacturer part, supplier part or develop part in the package is being modified for the first time, then the original element is preferably copied to the ‘DeltaOld’ element in the package. After the original information has been secured in this way, the element in the package can be edited. The ‘DeltaOld’ element will thus contain all originals and their underlying elements and attributes. If an element is edited, then this can be indicated by the additionalAttribute elements ‘deltaEditStatus’ (it will receive the value “Edited”) and ‘deltaOldItemUniqueIdentifier’ (which will contain a pointer to the corresponding element under ‘deltaOld’). In this way only the original element and the latest edited element are stored in the package. Intermediate states, that may have occurred when the element was edited multiple times after another before sending, will not be kept If new elements are created in the package, for example a new Item is added to the product structure, or a new Document is created, then this will be indicated by the additional attribute ‘deltaEditStatus’, which will receive the value “Added”.
It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as partially compiled form, or in any other form suitable for use in the implementation of the method according to the invention. The carrier be any entity or device capable of carrying the program. For example, the carrier may include a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk. Further the carrier may be a transmissible carrier such as an electrical or optical signal which may be conveyed via electrical or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant method.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb “comprise” and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article “a” or “an” preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
Number | Date | Country | Kind |
---|---|---|---|
03104196.5 | Nov 2003 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB04/52311 | 11/4/2004 | WO | 5/9/2006 |