PALMA – Engineering Interfaces Focus on Mechanical Engineering

1. PALMA – Engineering InterfacesFocus on Mechanical Engineering olivier.rives@thalesgroup.com +33 (0)1 6933 0019 December 17th, 2007

2. THALES’ PLM • Problem statement • Functional capabilities • Approach • Interface format & technology • Proof of concept • Next Steps & Roadmaps

3. THALES’ PLM

4. THALES’ PLM - Principles • Architecture : Distributed PLM Components • Engineering CoreModels/Environments == Authoring environments • Mechanical Eng., Electronics Eng., Cabling, • Systems Eng., SW Eng., ILS • … • «Transverse» CoreModels == Consolidation & Execution • PDM CoreModel (PALMA) == Configuration Management • ERP CoreModel (B-One) == Procurement, Manufacturing,…

5. THALES’ PLM – Engineering Environments • Engineering environments have strong differences • Technologies • Maturity • Different interpretations of common processes • Single or multiple sourcing of COTS • Engineering environments • Many • Specialized • Technology-dependant • Often developed by Business Units => Not generic nor reusable

6. THALSIS PM BI OCM TCIS ATPM ATDM ATSL Kiwi PEREN TMDM ATGM ATIM PALMA THALES’ PLM System – CoreModels Overview CHORUS Master Data Pilot Suppliers Mgt. ORCHESTRASW B-One Buy, Build & Support ORCHESTRASE Manage COTS Design Report Identification Control & Manage System/Product Reference THALES Net (eDir, THALES Pass, Employee Portal...)

7. THALES’ PLM – Interface needs for PALMA Kiwi ERP Identifiers Generator Spares, Support BOM,… ATSL ATSL MRP Mfg. Rsc . Planning ILS ILS M-BOM + ECO OM As As - - Supported Supported Order Management Built-BOM BOM Shipment # IB Delivered BOM Installed Base Services To To - - Be Be - - Applied Applied Maintained BOM Asset Management As As - - Specified Specified As As - - Designed Designed As As - - Planned Planned As As - - Built / Built / As As - - Maintained Maintained Fleet Management As As - - Delivered Delivered Maintenanceevents MRO ? BOM, BOD ,Breakdown ,files, vizualisation Maintenance/Repair Approved Design Changes AP233 ? ORCHESTRA ORCHESTRA ORCHESTRA ORCHESTRA ATDM ATDM ATGM ATGM ATIM ATIM SE SE SW SW Detailed Technical » Electronics Electronics Mechanical Mechanical Cabling. Cabling. Engineering ORCHESTRA H2WB

8. Problem Statement

9. Problem Statement • How to build CoreModels/Engineering Environments interfaces ? • Independent from vendors’ technology • Having a sufficient functional coverage • Supporting extensible data models • Providing room for growth of our PLM system • How to pool interfaces developments ? • Between CoreModels • Avoiding multiple, redundant developments • What –business- data-model to use ?

10. Solutions Identified – Data Format • One issue common to all solutions • Diverse data models shall be mapped together whatever the technology • Some possible pivotal formats • A THALES’ format ? • Best-fit ! • Time & cost to develop, technology to develop, not open… • PLM-XML (SIEMENS) • Made public by owner, XML-based, full life-cycle + geometry, API & SDK • Proprietary, not a real std • 3D PLM (Dassault/IBM) • Made public by owner, XML-based, full life-cycle + geometry, API & SDK • Proprietary, not a real std • STEP AP214 • Official ISO std, mature, proven, technology available • Life-cycle coverage • STEP AP239 (PLCS) • Official ISO std, APIs & SDK available, supported by several governments, DataModel coverage similar to PALMA • Still young

11. Solutions Identified – Why PLCS ? • Data Model coverage similar to PALMA • Similar « depth » • Similar life-cycle extend • Should cover most of needs for PALMA/engineering exchanges • Vendors & technology available • More a problem of « when » than one of « should » • Adopted by more & more customers => deliverables

12. Solutions Identified – Data Transport • Applications Integration (EAI)  Security, Stability, Real-Time able  Cost, know-how, development effort, high TCO, proprietary technologies • Databases Federation  Holistic data model, Single point of interface, shared repository  Maturity, unproven scalability • Peer to Peer exchange services (SOA)  Flexibility, scalability, no Single Point Of Failure, Real-Time able  Maturity • Files Based Exchanges  Simplicity, scalability, mastered for decades, low risk  Not real-time able, loose security

13. Expected CapabilitiesMechanical Engineering Example

14. Expected Capabilities • Engineer shall be able to • Publish in PDM (PALMA) new and changes to • Parts, assemblies, documents, BOMs • Documents data files • Visualisation files • Elements published shall have a controlled configuration status • Get approved changes (ECR) regarding the design he is working on

15. ATGM situation • Present • CAD Data Management Oriented • CAD Models Management + CAD Files • Models BOM • BOM and documents are generated from Design Database, not from PDM • Target • Incorporate BOM management • Dual structure : • Models BOM => CAD Data Management • Related Parts BOM with traceability links => Workbench deliverables management and link with product configuration • Note : Parts Breakdown and Model BOM can differ, New Model Rev does not mean new part Rev

16. Parts Breakdown Models Breakdown                                                           TARGET PRESENT ATGM DataModel Presently ATGM manages only the WIP data, thus of CAD Models data management oriented. Presently in the Models BOM, some models represent parts, they can be detected thank to their identification scheme. In the target system, the CAD environment PDM will have its own Parts BOM, each parts will be related to the corresponding CADModel in the Models BOM. Remark : Remark : One of the objectives of the ATGM (like any other workbench) is that it can be fully autonomous as not all group companies(will) have an enterprise PDM. Document  Actual file Model  Visualization (neutral format) file Part  Object having a « company » ID

17. ATGM DM Capability, Present Vault ATGM         Pro/E PDMLink                           (WIP)               EPMdocuments (== 3D files) Design Documents   ATGM Data consists in Models BOM made of models linked together and of engineeringdocuments (drawings,…). Only data having received an actual company identifier can be considered forexport thus, having such an identifier can be used as a way to identify data to be transferred. In THALES, native CAD files are not published into the enterprise PDM, only form of these files thatcan be read without CAD tools maybe transferred (visualization). Workspace  Actual file Document Model  Visualization (neutral format) file Baseline  Object having a « company » ID

18. PALMA Situation • Present : PALMA V1 • AsSpecified / AsDesigned scope • Part-centric PDM • Import / export based on editor’s native format and technology • File-based, XML • Does not cover actual files (attachments) import/export • Documents contents, parts visualisation files • Future : PALMA V2 • V2.0 = PALMA V1 + AsPlanned + AsBuilt + AsDelivered (almost done) • V2.1 = PALMA V2.0 + To-Be-Applied + AsSupported + NC (in progress) • Additional Import/export, cvs based, to ease exchanges with contractors • In fact CSV – XML conversion, XML remaining editor’s native • Support for files attachments import/export • PALMA Data Model • Several types of Parts, each with dedicated attributes & LC • Several types of Documents, each with dedicated attributes & LC

19. ATGM – PALMA Exchange, Dynamics (TARGET) • ATGM User Designs • Models Generation or Update • Library Models use • Models BOM • Documents Generation or Update • ATGM User Designates Models representing actual parts (not simple CAD artefacts) and designates documents to be published • ATGM asks for an ID for new parts or documents (to « Kiwi », ID generation Engine) • The ID is created with a « reserved » status • The part and document objects are – automatically- created (inWork) in ATGM PDM • ATGM User creates/updates the Parts Breakdown + documents • Parts Breakdown does not necessarily reflects models breakdown • ATGM User Review Parts Breakdown • « Reserved PN » are « confirmed » (a « Kiwi » transaction) • Parts & documents checked-in (+ neutral visualization files generated) + released • Business rules apply to check consistency of corresponding model • A named-baseline is created • ATGM-PLCS logic pulls data from baseline and map them • On PDM request

20. Approach

21. Approach • Perform standards and technology review • Select data-format & transport technology • Perform a Proof Of Concept • Representative : Mechanical / PDM exchanges • Simplified • End-to-end PTC technology • Simplified dynamics • Focus on data only • In partnership with specialists • PTC • Eurostep : specialist of PLCS • Proving • Data standard adequacy • Technology ability • Partners capability • Complete validation with adoption cost aspects (licences…) • Implement in ATGM,ATDM,ATIM

22. POC Objectives • Prove usability of PLCS as a pivotal format • Concepts coverage • Extensibility / Scalability • Prove technology ability • Data extraction and mapping • Identify necessary ATGM & PALMA improvements/changes • Identify process changes

23. POC Principles • 1) Simplify • Separate data model and transport technology • Use simplest possible transport technology : files exchanges • Work with technologically (as much as possible) similar components • Limit study to one single couple of CoreModels • Limit to engineering scope (AsDesigned) • Delay commercial aspects after technical results of POC • 2) Prove usability of selected data model (PLCS) • Coverage of « natural » Data-Mapping • Ability to cope with additional data • Metadata + files • 3) Prove data mapping technology • Generate data from authoring environment and map to target format • Map target format to native format of one of receiving application

24. ATGM – PALMA Exchange, Dynamics (POC) • ATGM User Designs • Models Update • Library Models use • Models BOM • Documents Generation or Update • ATGM User Designates Models representing actual parts (not simple CAD artefacts) and designates documents to be published • Giving documents and recognisable IDENTIFIER • ATGM User Review Parts Breakdown • Models & documents checked-in (+ neutral visualization files generated) + released • A Baseline is created • ATGM-PLCS logic pulls data from baseline and map them • On manual request. Resulting data delivered in a shared directory.

25. ATGM => PALMA POC / BOM publish use-case • Generate BOM-like format + related documents from models breakdown • Collect visualization files when they exist (for parts and documents • All models concerned shall be put into a dedicated named baseline, managed by the ATGM PDM. For being put into the baseline, they shall be at the released state. • The Data extraction shall be based on the contents of the named baseline, Revision information is not required for the POC. • The mapping to PLCS shall be checked in order to demonstrate no data loss • PALMA import requires that all parts & documents to be updated are already existing in the PDM and checked-out • Import shall replace/update only data that where tagged as originating from the ATGM.

26. ATGM => PALMA POC / Changes Use case • PALMA shall deliver to ATGM a list of approved ECR related to current ATGM parts and documents the engineer is working on • Scenario : ATGM user asks for change status for a part • ATGM extract parts’ breakdown and generates a flat file with no repeats • Extract real parts + related documents Ids • ATGM sends list to PDM • PDM extracts for each of the IDs submitted • List of approved ECRs (+ URL) applicable to the revisions stack existing between present ATGM revisions and PDM last revision • ATGM users gets • List of parts + applicable ECR (+URL)

27. POC Partners

28. POC Partners • PTC • One the group’s preferred vendors • Present in CAD, PDM • Knowledge of our environment • Eurostep • The prime-contractor for PLCS creation • Main bases in UK & Sweden + office in France • Provides : Know-how, training & technology

34. POC Results

35. POC Results • ATGM => PALMA • Ability to transform ATGM BOM to PLCS BOM • Ability to transform PLCS BOM to PALMA import data • Ability to extend PLCS for supporting THALES specific data • Ability to transfer documents’ files • Ability to import visualization files • PALMA => ATGM • Ability to extract ECR on BOM • Ability to transform result in PLCS data • Ability to transform PLCS change data into a HTML man readable form

36. POC Results • Still to do : • Partners worked on data files provided by THALES • THALES needs to re-integrate all developments • Lessons learnt : • PLCS does the job • Technology works • PLCS requires some know-how to perform an efficient data-mapping => training required • Conclusion : • Technical Feasibility is proven

37. Next steps

38. Next steps & Roadmap • Check commercial aspects (with Corp procurement) • See if room for corporate negotiation • Feedback session (end January, date TBD) • Specification for • PALMA V2 and ATGM/ATDM/ATIM • Objective end Q1 2008 • Development • Prototype : end-Q2 • Finalized : October 2008*** • Generalization to • all THALES Workbenches including Orchestra + ERP (TBC) • *** shall comply with DLJ PALMA Roadmap • (final qualification : October 2008 / In operation : December 2008)

39. THALES’ PLM – Interface target for PALMA Kiwi PLCS ERP Spares,Support BOM,… PLCS Identifiers Generator ATSL ATSL MRP Mfg. Rsc . Planning ILS ILS PLCS M-BOM + ECO OM As As - - Supported Supported Order Management Built-BOM BOM Shipment # IB Delivered BOM Installed Base PLCS Services To To - - Be Be - - Applied Applied Maintained BOM PLCS Asset Management As As - - Specified Specified As As - - Designed Designed As As - - Planned Planned As As - - Built / Built / As As - - Maintained Maintained Fleet Management As As - - Delivered Delivered Maintenanceevents PLCS MRO ? BOM, BOD ,Breakdown ,files, vizualisation Maintenance/Repair Approved Design Changes AP233 ? ORCHESTRA ORCHESTRA ORCHESTRA ORCHESTRA ATDM ATDM ATGM ATGM ATIM ATIM SE SE SW SW Detailed Technical » Electronics Electronics Mechanical Mechanical Cabling. Cabling. Engineering ORCHESTRA H2WB

40. Thank you for your attention More Info ? THALES EPM Domaine de Corbeville 91400 Orsay olivier.rives@thalesgroup.com +33 (0)1 6933 0019