Architecture of reference used for definition of the TDP message TDP message aims to collect information for secured transportation of Technical Data Package files between industrial partners and their applications.
The scope is very simple and restricted, in order to be able first to obtain easily a first component of a hugger set of standards for eBusiness PLM interoperability.
The idea is also not to be any community framework dependant. As an exemple, Aerospace&Defence community in the US use STEP AP203 or STEP AP239 when AP214 is prefered in Europe, even if developed initially by Automotive. Some other domains may use other specific standards. As eBusiness PLM collaboration can involve enterprises coming from different communities (and not only Aerospace & Defence), the idea it to produce a tranportation mechanism that can be adapt to any used protocol for Product Data Interchange, using eventually some translation services. But the TDP message header remains the same in all case, secured transportation being decoupled from data exchange and sharing.
Other justification is to provide agile and flexible specifications, which will not be impacted by evolution of practices and used application protocols. Exploitation can be started with protocols currently used by legacy programs, and then some evolution of the protocols is possible without impacting TDP message specifications and secured file transporation.
This decoupling can be illustrated through the following figure.
The Technical Data Package can be regarded as a "container/carrier file", which collects all relevant data for file transmission. The Technical Data Package is a set of:
- Product files (one to n digital files)
- Product metadata (one file if monolithic meta-data file is used, n is shattered meta-data files are used
- data dispatch note (TDP Message)
TDP message, for a minimum, shal provide information on sender, receiver and list of all digital files of the TDP in order to support automatic routing, acknowldegment and validation of transportation of the TDP and tis content. Further TDP message attributes are to be defined to cover the full spectrum of needs.
The Product meta-data which provides information allowing to import of its meta-data and related TDP product data into the receiving target system are out of scope.
The requirements associated to the TDP are the following:
Requirement A: including a minimum set of required and commonly defined attributes
Requirement B: TDP transfer process must be independent of the Product meta-data and associated Product Data import/export process:
- in order to support any way to define the Product meta-data format (e.g. STEP AP214/AP203/AP242/AP233... , part 21/part28, monolithic or shattered, etc)
- TDP transfer and product data exchange beween systems are two different needs and distinct processes, but have to be consistent and harmonized.
Considering a Service Oriented architecture, the different kind of considered applications which can be involved are:
- a "TDP producer" application (e.g. a Product Data Management system)
- a "TDP consumer" application (e.g. a Product Data Management system or a CAD system)
- a hub system providing secured transportation capability for the content of the TDP, and associated traceability
Eventually, collaborative central repository with data federation capabilities can also be considered, which have to be distinguished from PDM systems. This kind of application can also be a TDP consumer, for data pushed from a PDM to collaborative environment through a TDP.
TDP producer will be different according the phase of the lifecycle with is considered. As first pilots focussed mainly on design phase, the TDP producer and consumer are PDMS systems of the involved partners, but can also be some Computer Aided Design tools dealing with mechanical digital mock-ups. But for other phases of the lifecycle, it can be as well Requirement Management systems, Simulation Management Systems, Enterprise Resource Planning Systems or Customer Support systems. The Product meta-data can then be based on different application protocols.