Whitepaper. Development of a Convergent Modular STEP Application Protocol Based on AP 203 and AP 214: STEP AP 242 Managed Model Based 3D Engineering

Transcription

1 Whitepaper Development of a Convergent Modular STEP Application Protocol Based on AP 203 and AP 214: STEP AP 242 Managed Model Based 3D Engineering Version PDES, Inc. V.: 1.0 Update:

2 Table of content 1 Executive summary Introduction Context of the start of the activity History of the Convergent AP activity Basic requirements of the aerospace and defense industry Basic requirements of the automotive industry Scope of the standards Benefits of and Business drivers for a convergent AP based on AP 203 ed2 / AP 214 ed Benefits of Developing a Convergent Application Protocol Usage scenarios and use cases Requirements for the convergence of AP 203 and AP Scope of the proposed AP Functionalities both in AP 203 and AP Functionalities in AP 203 only Functionalities in AP 214 only New functionalities Migration strategy Impact on complementary standards and applications OMG PLM Services SASIG ECM Recommendation NAS 9300 / EN9300 standard, for long term archiving and retrieval of 3D digital aerospace product information Consistency with ISO 3D light visualization specifications Risk management for the convergent AP Project Plan...40 V.: 1.0 Update:

3 9.1 Project organization Financial principles Deliverables Costs Scheduling Responsibilities Summary next actions Annexes...54 Annex A AP 242 Detailed Scope...54 List of figures Figure 1 Usage scenarios covered by AP Figure 2 Business Object Model and AM Figure 3 Implementation scenarios supported by AP Figure 4 Dependencies between AP 214 edition 3 and OMG PLM Services, V Figure 5 Alternative implementation forms for ECM interfaces...33 Figure 6 EN9300 Part structure...35 Figure 7 Project Organization...41 Figure 8 Distribution of costs over work packages...46 Figure 9 Distribution of costs in terms of priority...46 Figure 10 Project plan...49 Figure 11 Distribution of costs over time...50 List of tables Table 1 Details of usage scenarios as business drivers...18 Table 2 Details of extended functionality as business drivers...21 Table 3 Responsibilities...51 V.: 1.0 Update:

4 History Version Date Summary of the change Name V Initial version P. Rosche / JYD V Version with comments of 25 th Aug teleconf V Version with comments of 1 st Sept teleconf V Version with workshop results Max Ungerer V st Draft for Review with major chapters included Max Ungerer V Main comments done by ASD SSG members Jean Yves Delaunay V Incorporation of review comments Max Ungerer V Interim version with comments and decisions from conf call Max Ungerer V Ch. 1 include; figures improved; minor changes Max Ungerer V Final Draft for review Max Ungerer V Final Draft for review with comments Max Ungerer V Final Draft with review comments included Max Ungerer V Final Version Max Ungerer V.: 1.0 Update:

5 1 Executive summary The competitive nature of the global marketplace has forced manufacturers to reduce expenses and become as responsive as possible to changing market requirements. Successful design and manufacturing enterprises and their supply chain partners must invest in the latest model based development and product lifecycle management solutions in order to remain competitive. Model based development and product lifecycle management include a wide variety of functions that must share data. If these functions are provided by tools from the same software vendor, then system integration is achieved by virtue of a single common data exchange framework defined by that vendor. Complete coverage of all functions desired in an enterprise is rarely achieved by a single vendor, however, is difficult to maintain over time, and customers became dependent from that vendor. Companies today design, manufacture, and provide support for their products as part of a global, distributed enterprise. Acquisitions, mergers, preferred supplier relationships, and a desire to use bestin class solutions result in a disparate set of software applications rather than a monolithic solution. Even very large companies have found it cost prohibitive to consolidate the entire enterprise on a single CAD/CAE or PDM/PLM system. Large OEM 1 s initially tried to deal with supply chain integration issues by insisting that all their suppliers use specific software solutions. This approach to integration limits the suppliers freedom to use tools that are most efficient for their business and adds cost as suppliers must maintain different systems for each customer. A successful approach to support new capabilities and control costs is to implement data exchange standards that allow companies to integrate all phases of the product lifecycle using the most cost effective solutions regardless of the solutions adopted by other parts of the enterprise. Low cost CAD systems, viewers, and 3 rd party engineering analysis and computer aided manufacturing (CAM) systems make it possible for even small companies to compete in a high technology environment on a cost competitive basis. The STEP standard focuses on product data representation to support CAD/CAE and PDM data exchange, system integration, visualization, and long term preservation of product information. The automotive and aerospace industry in the US and Europe helped establish organizations to ensure the overall consistency of CAD and PDM information interoperability specifications. Two STEP standards that are widely implemented are AP 203 maintained by PDES, Inc. and AP 214 maintained by ProSTEP ivip and SASIG 2. AP 203 is primarily supported by the aerospace and defense industry. AP 214 is used primarily in the automotive industry. Both standards are widely used in the supply chains of many industrial sectors. Both the AP 203 and AP 214 standards have recently issued new revisions. AP 203 developers worked with industry users to identify information requirements to support new functionalities, such as, 3D Product Manufacturing Information (which includes Geometric Dimensioning & Tolerancing), 1 Original Equipment Manufacturer 2 Strategic Automotive product data Standards Industry Group V.: 1.0 Update:

6 composites design data, and data quality. PDES, Inc. and other AP developers also introduced a new modular architecture for STEP to improve integration across AP implementations and substantially reduce standards development time and maintenance. ProSTEP ivip has identified similar needs and potential interest for a modularization of AP 214. The two standards share common data structures, but have some differences. Rather than pursue costly parallel development and maintenance efforts, developing a new, convergent STEP standard has been proposed. This new standard is an opportunity to introduce new functionality, optimize development and maintenance resources, and strengthen the acceptance and support of STEP by the main manufacturing industries. This whitepaper summarizes the business requirements, use cases, and benefits for industry on the one hand, and provides the detailed project planning (resources, deliverables, scheduling, costs, financing, project organization and responsibilities) on the other hand to enable the relevant organizations and industry stakeholders to decide whether to start a related initiative or not. The major technical impact of the convergence effort will be in the areas of PLM integration, PLM services, Long Term Archiving (LTA), Model Based Development (MBD), supply chain integration, engineering design data exchange including composites, advanced Product Manufacturing Information (PMI), mechatronics, and systems engineering. The new STEP standard will be complementary to popular visualization formats, such as Adobe and JT, and will support advanced data content, such as advanced PMI, composites, and mechatronics. The vision of the ASD 3 Strategic Standardization Group (SSG) is of a consistent set of full 3D configured product model based standards for product information exchange, visualization, long term archiving, sharing, and quality control. Certain capabilities provided by AP 214 that are not included in AP 203 are of interest to the group in achieving that vision. Continued separate development of AP 203 and of AP 214 represents a risk to the realization of this vision. Automotive stakeholders in the development of STEP include SASIG, JAMA 4, Odette International, VDA 5, ProSTEP ivip, as well as Chinese and Korean automotive industry associations. The automotive sector implements AP 214 and various derivatives of the standard. The OMG 6 PLM services that are based on AP 214 are a mature, operational technology. The AP 214 Geometric Dimensioning and Tolerance (GD&T) model is widely used, as is the engineering change capability. The automotive industry supply chain is currently focused on visualization as one of the supply chain enablers. Advanced data structures developed for STEP standards will help drive new visualization capabilities. 3 AeroSpace and Defence Industries Association of Europe 4 Japan Automobile Manufacturers Association 5 German Association of the Automotive Industry 6 Object Management Group V.: 1.0 Update:

7 A critical priority in the aerospace sector (and increasingly in automotive) is the need to address longterm product model maintenance (archive). Because of the recent gains in visualization technology, it is no longer acceptable to just maintain the STEP product model and native CAD model. Traceability between the reference STEP product model and the visualization product model is a requirement because the visualization industry has not adequately addressed long term product data archiving issues. Improved supply chain integration is a prime motivation for both sectors. The AP 214 model is the source for the OMG PLM services model. The OMG PLM services XML schema is based on direct compilation of AP 214. The OASIS 7 PLCS XML schema is based on AP 239, which is a modularized AP and shares many data structures with AP 203. There is great potential for aerospace to re use the OMG PLM services in addition to the OASIS PLCS services. Product Manufacturing Information (PMI) capability is critical to future supply chain activities. STEP needs to be extended based on recent changes to ISO Technical product documentation Digital product definition data practices and the relevant ASME 8 standards. Both AP 214 and AP 203 would eventually need to be updated to maintain compatibility with these specifications. Other areas of interest to both the aerospace and automotive industry are mechatronics, parametrics, electronics, sustainability, data quality, and the exchange of material data for compliance with environmental regulations. Developing a convergent standard will add new, important capabilities to STEP. The convergent standard will substantially reduce development costs due to a single development infrastructure and utilization of the new, rapid development and publishing environment. The rapid development and publishing environment will allow standards developers to create extensions in smaller batches (lean development). Smaller batch size will result in lower cycle time, leading to broader adoption of STEP. 7 Organization for the Advancement of Structured Information Standards 8 American Society Of Mechanical Engineers V.: 1.0 Update:

8 2 Introduction 2.1 Context of the start of the activity All new development efforts in the aerospace and automotive industry are based on 3D model based design methods, extensive use of the global supply chain and heterogeneous commercial off the shelf CAD and PDM systems. This has resulted in increasing business requirements for the interoperability of CAD PDM information, in order to achieve the development efforts on or under budget, on time, and with a high degree of quality. The development of the initial editions of AP 203 and AP 214, which commenced in the early 1990 s, were focused on product data exchange. New processes have resulted in specialized functionalities for exchange, integration/sharing through Service Oriented Architecture SOA 9, visualization, and long term preservation of 3D design information. For this reason, the US and European aerospace industry has set up organizations to ensure the overall consistencies of open PLM standards, with the development of policies for CAD and PDM information interoperability. ProSTEP ivip has identified similar needs and potential interest for the modularization of AP 214, in order to simplify updates with the new STEP functionalities such as 3D PMI. The convergent AP project is an opportunity to optimize resources and strengthen the acceptance and dissemination of this new STEP standard by all industries worldwide. In the case of failure, the aerospace and defense industry on the one hand, and the automotive industry on the other hand, may diverge to develop and maintain different ISO standards. 2.2 History of the Convergent AP activity For 20 years a significant amount of effort has been made by the aerospace and automotive industry to develop the ISO STEP standards. AP 203 edition 1 was published in 1994, primarily driven by aerospace and defense requirements and developed and maintained by PDES, Inc. AP 214 edition 1 was published in 2001, driven primarily by automotive requirements, and developed and maintained by the ProSTEP ivip and SASIG organizations. Harmonization has been ensured by the use of agreed methods and recommended practices for the exchange of CAD and PDM information under the coordination of ProSTEP ivip and PDES, Inc. Nevertheless, since 2004, 5 main technological breakthroughs have occurred: 1) AP 203 edition 2 is a significant improvement over AP 203 edition 1, covering 90% of the content of AP 214, and it is based on the improved ISO TC 184/SC 4 modular approach. The AP 203 edition 1 information model has been extended to include: a. complex configuration management based on specifications of AP 214, b. 2D drawing information (from AP 202 and AP 214), 9 Service Oriented Architecture V.: 1.0 Update:

9 c. 3D composite design (from AP 209). d. Requirements information (from AP 210 and from AP 233) 2) The development of the OMG PLM Services, based on the AP 214 ARM information model, and the PLCS PLM Services, based on AP 239, providing SOA capabilities for PDM integration within the OEMs and within the Supply Chain. 3) The development of DEXs 10 as a method to define subsets of an AP with associated Recommended Practices 4) The emergence of usage of Reference Data Libraries (RDL) 5) The accelerated development of 3D lightweight visualization formats since ) The strong involvement of the US and European aerospace industry in the LOTAR project to develop an international standard for long term preservation of 3D design product information. 7) The setting up of coordination structures within the AIA 11 and the ASD, to ensure the consistency of e business standards, based on a similar interoperability architecture framework. Both organizations have identified the interoperability of integrated CAD and PDM information as key tasks, and have established project teams to address these issues (AIA EDIG 12 and ASD SSG PLM working group ). The ASD SSG working jointly with ProSTEP ivip, and NIST working jointly with PDES, Inc. have identified an opportunity for a convergent AP, based on AP 214 edition 3 and AP 203 edition 2. The first teleconference occurred on the 9 th of July Additional teleconferences were set up in August and in September, resulting in the organization of a 3 day international workshop on the 23 rd 25 th of September 2009 in Darmstadt Germany. As a response to these initial activities, ISO TC 184/SC 4 has reserved a part number for the convergent AP: ISO There are no further plans on the ISO level yet. Further action shall not happen before the convergent AP project is accepted by the stakeholders. Nevertheless, for convenience reasons in the remainder of this whitepaper, the term AP 242 is used for the convergent AP. 2.3 Basic requirements of the aerospace and defense industry The main technical requirement for AP 242 is to become the cornerstone standard of the cross process capabilities for interoperability of core engineering design information under configuration management, that is to say, 10 Data Exchange Specifications 11 Aerospace Industries Association 12 Engineering Data Interoperability Group V.: 1.0 Update:

10 providing specifications for exchange and long term archiving, providing a consistent business object model used for PLM web services, and being the reference for the mapping to ISO 3D light visualization specifications. AP 242 shall rely on the modular approach in order to ensure the consistency with other modular APs, covering the full product life cycle and the main disciplines: AP 233 ( Systems Engineering ), AP 209 (Analysis and simulation), AP 239 ( Product Life Cycle Support ), AP 210 ( Electronic assembly, interconnect and packaging design ). 2.4 Basic requirements of the automotive industry The main automotive technical requirements for AP 242 are the following: to provide all the functionalities of AP 214 ed3, to manage the upward compatibility of AP 214 and the OMG PLM Services, to provide possible scope extensions (via the modular approach) for e.g. shape quality, parametrics, requirements management, etc., to gain broad worldwide acceptance of the new standard by users and vendors, the broad availability of software products supporting the new standard. 2.5 Scope of the standards AP 242 version 1 will provide at least all the functionalities covered by the AP 203 ed2 and AP 214 ed3. It is sought to include the Shape Quality modules, derived from STEP Part 59 and based on the SASIG PDQ guidelines. Extensions should be mutually agreed upon by the stakeholders of the development of the project. V.: 1.0 Update:

11 3 Benefits of and Business drivers for a convergent AP based on AP 203 ed2 / AP 214 ed3 3.1 Benefits of Developing a Convergent Application Protocol Combining AP 203 and AP 214 into a single convergent information model provides benefits to both the user and vendor communities, and the automotive and aerospace industry. Some of the benefits identified are found below. ProSTEP and PDES, Inc. combined their resources for testing CAD system implementations of the STEP standard 10 years ago. This combined testing forum is called the CAx Implementor Forum (CAx IF). The objective of the forum is to accelerate CAx translator development and ensure that user's requirements are satisfied. The development of AP 242 would take a similar approach to the CAx IF but with participation from a broader group of organizations. This collaboration from a large number of organizations and industries provides a larger resource pool than would be possible otherwise and would spread the cost across a wider group of organizations. This broader collaboration would also result in acceptance across a broader range of industries. The development of the convergent AP provides an opportunity to add new capabilities not currently found in AP 203 or 214. Some of these capabilities would be product data quality, support of cable and wire harnesses, systems engineering, composites design and manufacture, and product management data sharing in a Systems Oriented Architecture. The modular approach improves the interoperability of Application protocols. Applications based on different application protocols can share their data. Error corrections and minor changes to APs can be much faster due to the establishment of the modules database (STEP Part 1000). ISO has simplified the maintenance process to publish new versions faster. Throughout the 10 years of CAx IF testing there have been a number of instances where AP 203 and AP 214 have represented an identical concept in a slightly different manner. This mismatch caused CAD and translator developers to have to develop approaches that would handle the differences in the models. Developments of these dual approaches have caused an additional burden on the vendors from the standpoint of a higher development cost. Therefore vendors would prefer supporting only one AP. The message from the automotive and aerospace industry worldwide to implement the new AP will be the single target for vendors. Another issue that has impacted users and vendors alike is the time phased functionality mismatch between AP 203 and AP 214. Since AP 203 has become a modular data model, changes to it are made in a relatively timely manner. Changes to AP 214 have been more phased to correspond to ISO standards releases. Development and implementation of the convergent AP will alleviate this mismatch in functionality. Another aspect of this has to do with the harmonization between the two standards. Due to the different architectures of AP 214 and 203, harmonization of the two standards has been time V.: 1.0 Update:

12 consuming and difficult in some instances. Time consuming harmonization between the two data models will no longer be necessary with creation of the convergent AP. For the long term archival of design data, STEP provides the best alternative due to a number of its attributes: STEP is both human and computer interpretable The STEP standard does not change as often as commercial software used in industry and government STEP is software independent STEP is an international standard Due to these reasons and more, STEP has been chosen by various aircraft certification bodies as the product model to use for the long term archival of technical data. By development and implementation of the convergent AP, commercial aircraft manufacturers will only have to support one product model since they sell their products globally. This concept is an enabler of globalization, and the result would be a truly International Standard. Many first, second, and third tier suppliers support numerous industries. Over the years the use of AP 214 has been more common in the automotive industry, and AP 203 has been more prevalent in the aircraft industry. From a CAD standpoint, the implementation scope has been nearly identical between these two APs. Supplier confusion has been common due to receiving different STEP standard files from OEMs in different industries. Creation of the convergent AP and software development by vendors will cease this confusion. Additionally, most if not all OEMs today are global industries. Therefore the convergent AP can be seen as an enabler of globalization. While at the Application Interpreted Model (AIM) level of AP 203 and 214 are very similar, at the Application Reference Model (ARM) level, they are considerably different. CAD systems have implemented at the AIM level through the STEP physical file format, Part 21. Product Data Management (PDM) systems lend themselves more to ARM implementations using XML due to the less granular nature of their business objects. To make the convergent AP as useful as possible, it will contain a mapping from the ARM of AP 424 to the business object model of AP 242, which will be mapped to an implementable XML schema. The convergent AP will provide a unified approach to Product Data Management information exchange. 3.2 Usage scenarios and use cases The business drivers for a convergent AP are based on the following usage scenarios and use cases. Figure 1 gives an overview on the usage scenarios. V.: 1.0 Update:

13 Customer 2. Supplier Supplier data data exchange exchange 4. Data Supplier Data sharing sharing data exchange on SOA Data on SOA basis sharing basis 5. Engineering on SOA basis Visualization Visualization Manufacturer 1. 3D Model based design 3. Long term archiving 6. Domain integration (Engineering analysis, Manufacturing simulation, Inspection planning, etc.) Supplier 1. 3D Model based design Figure 1 Usage scenarios covered by AP 242 Product design with a 3D master model including all the information typically on technical drawings, e.g. product manufacturing information, within this 3D model in order to avoid technical drawings completely. Business driver for automotive and aerospace: Save efforts for drawing creation and gain efficiency, e.g. for downstream processes, by a unique 3D model based master design that covers all the information. 2. Supplier data exchange Business driver for automotive and aerospace: The supply chain gains importance (increasing work share and responsibility) for the final product. Therefore an efficient and complete exchange and/or sharing of the product definition is important. The most efficient method is to base the exchange and/or sharing on one standard. 3. Long term archiving Business driver for aerospace: V.: 1.0 Update:

14 Documentation of aerospace and defense products have to be available more than 50 years, therefore long term archiving based on 3D model design is a strong requirement. 4. Data sharing on SOA basis Business driver for automotive and aerospace: The extension of complete support of the product life cycle for design, manufacturing and support in service to include exchange with customers (airlines, fleet, ) in the service life cycle, is necessary. Therefore compatibility both with the OMG PLM Services and with AP 239, which is the AP for product life cycle support, (PLCS) is required. 5. Engineering Visualization Business driver for automotive and aerospace: Since the number of data consumers is much higher than the number of data creators (internal and external suppliers) an engineering visualization strategy based on a lightweight visualization format can save significant license costs for data consumers while increasing the availability of 3D product data for all kinds of applications. Business driver for aerospace: Use of one single standard AP 242 for the long term archive provides a consistent mapping to separate performance optimized visualization formats. 6. Other usage scenarios, including o Design to Engineering Analysis o Design to Manufacturing data exchange o Design to Manufacturing simulation o Design to NC planning o Design to Inspection planning Table 1 gives the details of the usage scenarios, the priorities and the benefits of a convergent AP. V.: 1.0 Update:

15 Business driver Description Auto Aero Vendors Coverage Benefit of convergence Business driver Priority Priority Usage Scenarios 3D Model based design High High High for PMI 3D Model based development No drawings High High Medium High Low High single PMI model. 3D PMI High High High Medium Shared resources to extend model PMI 1.0 PMI 2.0 High for recommended Supplier data High High practices and XML exchange implementation form Common data format for supply chain suppliers have multiple customers PDM data exchange High High High High Low High Depends on vendor High Medium Some benefit since vendors support only one AP less confusion for users High Combined resources for single AP and common set of recommended practices. Business Object Model to XML schema (many users want XML data exchange format) V.: 1.0 Update:

16 Business driver Description Auto Priority More related to recommended Incremental assembly practices. structure exchange Some High extensions to model may be needed Incremental CAD model and properties exchange Aero Priority High Vendors Coverage Benefit of convergence Business driver Depends on vendor High Medium would not need to develop in AP 203 Micro changes Low Low Low Medium Low not a high priority Long term archiving Medium High 3D Long term data archiving Data quality assurance PDQL part of this. STEP Part 59. CAD 3D geometry. Important for long term data archiving Medium High High High High Medium High Modules completed. Not yet implemented High for model extension efforts and for target of a single LTA standard High very important to users. Single AP less confusing. Share resources to extend model as needed High would be added to converged AP. Reduced effort (would not need to add to both APs) Documentation of aerospace and defense products have to be available > 50 years. Product liability is important for automotive, too. Therefore long term archiving based on 3D model design is a strong requirement V.: 1.0 Update:

17 Business driver Description Auto Priority Data sharing on SOA basis PLM Services (PLM SOA) Engineering visualization STEP to visualization Sharing of PDM information. Current model used for OMG PLM services. PDM is subset of PLM. Other industry formats used for visualization Aero Priority High Medium High Medium Low High High Low: JT as PAS used Vendors Coverage Benefit of convergence Business driver Depends on vendor High High Low High Kinematics Medium Medium Low Medium (in 214 now) High combined resources and common set of PLM Services for the complete lifecycle High Combined resources for single AP and common set of PLM services for complete lifecycle. Business Object Model to XML schema. Low specific visualization formats (e.g. JT) used, High share resources for kinematics Low single AP provides minor benefit. High share resources to extend current data model Extend life cycle for design manufacturing support in service, to include exchange with customers (airlines, fleet, ) in the service life cycle (AP 239 compatibility is required) Use of ONE standard (AP 242) for the long term archive requires a consistent mapping to a separate performanceoptimized visualization format (Visualization formats JT, U3D and PRC are considered) V.: 1.0 Update:

18 Business driver Description Auto Priority Aero Priority Other usage scenarios Low Medium FEA, Thermal, Design to Engineering save analysis Analysis results (AP High High Medium High 209) Design to manufacturing data exchange Design to manufacturing simulation Assembly sequence, discrete event (manufacturing layout) Design to NC planning Low Low Design to inspection planning CMM programming. Inspection features? Vendors Coverage Benefit of convergence Business driver Low Low Low High Low Medium benefit from modular architecture Medium Medium Medium Medium Low out of scope? Low Low Low Depends on vendor (CAM vendors High) relevant business driver for automotive and aerospace relevant business driver for aerospace only High geometry, PMI, form features Medium geometry and PMI available High form features in new AP. Single PMI model. Medium single PMI model would be benefit. Potential future priority. Table 1 Details of usage scenarios as business drivers V.: 1.0 Update:

19 The business drivers for AP 242 are based in addition on the following extended functionality that may be addressed by AP 242 or via compatibility with existing APs. 1. Mechatronics Business driver for aerospace and automotive: Aerospace and defense as well as automotive products include mechanical, electrical / wire harness, electronic and software components and systems. These have to be designed and verified in an interdisciplinary approach. Therefore the compatibility with AP 210 and with AP 233 is required. 2. Other functionality o Shape quality Business driver for automotive: In automotive industry worldwide product data quality standards are essential for collaboration in a global environment. Therefore SASIG has invested significantly in the SASIG PDQ Guidelines that are incorporated in the STEP Standard as STEP Part 59. Shape quality modules, based on STEP Part 59, can be included in the Convergent AP in order to make this functionality available for applications. o Macro cost calculation development o Sustainability (recycling, environmental impact) o Composites design and production Business driver for aerospace: New aerospace and defense products are all designed using composite materials. These have to be exchanged with suppliers; therefore the compatibility to AP 203 ed2 and AP 209 is required. o Piping and other routed systems Table 2 gives the details of the extended functionality, the priority and the benefits of AP 242. V.: 1.0 Update:

20 Business driver Description Auto Priority Extended functionality Aero Priority Mechatronics High High Mechatronics Wire Harness Other functionality Macro cost calculation development Sustainability (recycling, environmental impact) Requirements management Wire harness. AP 212. Piping? Part of mechatronics? Link cost to detailed design Very High High Vendors Coverage Benefit of convergence Business driver Depends on vendor High High Medium Medium / None Medium / High Medium Medium Medium Medium Medium Medium Low? Low in AP 212, but not in modules or AP 214 Medium cost attribute in AP 214 High gain compatibility with AP 233 (Requirements) and AP 210 (Electronics) High Combined resources for single AP. Gain compatibility with AP 233 and AP 210 High for composite materials, gain compatibility with AP 203 e2, AP 209 and AP 235 High share resources to extend current data model Mechatronics systems including mechanics, electrics / wire harness, electronics and Software have to be designed and verified in an interdisciplinary approach (AP 233 Systems Engineering compatibility is required) New aerospace and defense products are all designed using composite materials. These have to be exchanged with suppliers (AP 203 ed2 AP 209 compatibility required) V.: 1.0 Update:

21 Business driver Description Auto Priority Composites design and production Piping and other routed systems Important for ship building. Aero Priority None High Low None Vendors Coverage Benefit of convergence Business driver Depends on vendor relevant business driver for automotive and aerospace relevant business driver for aerospace only High (in AP 203) High would be added to converged AP. Compatibility with AP 209 important. Table 2 Details of extended functionality as business drivers V.: 1.0 Update:

22 4 Requirements for the convergence of AP 203 and AP 214 The proposed AP 242 is a replacement of the existing AP 203 and AP 214 while remaining upward compatible with these two APs. Therefore it has to be generic enough on the one hand to address both aerospace and automotive applications and to avoid industry specific terminology. On the other hand, the contents, functionalities and features of the two existing APs (e.g. definition, constraints, or examples) must be supported. The requirements for the proposed AP 242 are described in the following: Support of AP 214 definitions, constraints and examples AP 214 is much more detailed and precise than the modular APs with respect to definitions, constraints and examples. Therefore this information has to be preserved. Some of this AP 214 content may go into the module 442, the main module of AP 242. But also the application modules of the 1000 series used by AP 203 edition 2 have to be reviewed and enhanced by the existing AP 214 definitions, examples and constraints in order to use those modules in the context of the convergent AP. Business Object Model Due to the modular approach the modeling style for application objects defined in a module based Application protocol is much more generic than in a monolithic application protocol. As an example, the definition of the AP 214 application object Item is split within AP 203 over several objects like Product and Part. AP 214 shows on about 90 diagram pages all ARM concepts in a comprehensive way. The objects on the particular diagram pages are logically grouped by domains. This grouping is supported by a color scheme. This comprehensive ARM of AP 214 should be preserved in the new AP 242 for several reasons. Among them are: o The ARM is used for the communication with domain experts. o The ARM is the basis for SOA standards like the OMG PLM Services and ARM based business applications. Therefore the addition of the concept of a Business Object Model to the STEP architecture is proposed. A business object model is an information model which is on the same level of granularity as the AP 214 ARM. It uses the vocabulary of the STEP modules. For example, in the business object model you might find the object Part with explicit attributes id, name and description. The object Product would then not be in the business object model. The business object model can be transformed in an XML schema with the same granularity. The business object model provides a view on the AP 242 ARM Long Form. Consequently the business object model should be defined as an EXPRESS model with a mapping to the ARM of AP 242. The business object model and the mapping to the AP 242 ARM will be part of AP 242. The documentation form (EXPRESS G only, EXPRESS, complete with textual definitions and V.: 1.0 Update:

23 examples, normative or informative part, additional clauses and annexes) has to be discussed in detail yet. The introduction of the business object model is a new capability in the documentation of an application protocol. The starting point for the development of the business object model should be the current AP 214 Edition 3 ARM, which provides the right granularity of objects, but not the vocabulary consistent with STEP modules. The business object model shall have the granularity of the AP 214 ARM and be consistent with the information content / vocabulary of AP 242 ARM. The 242 ARM will look more like the current AP 203 edition 2 ARM to preserve the consistency with other modular APs. The intention is to define a single business object model for AP 242 with a mapping to AP 214. But it might be necessary to define several business object models for different business areas. The business object model should be complemented by a Business Object XML Schema for SOA applications. This XML schema should be derived from the business object model EXPRESS by an XML configuration specification according to ISO and be compatible to the OMG PLM Services Informational Model. There should be exactly one configuration specification defined in AP 242 to avoid different variations of the AP 242 Business Object XML Schema. AP 242 would have 2 implementation forms: o Part 21 files conform to the AP 242 MIM Longform schema, o XML files conform to the AP 242 Business Object XML Schema. The relationship between the two implementation forms is explicitly given in AP 242 by the mapping specification (ARM to MIM, clause 5.1), the mapping from the business object model to the ARM (new annex in AP 242), and the XML configuration specification (business object model to XML schema, new annex in AP 242). On this basis implementations can be realized to convert AP 242 Part 21 files into XML files and vice versa. Figure 2 gives the details of the business object model approach and its position in the STEP architecture. V.: 1.0 Update:

24 AP 242 Complete EXPRESS-G Definitions Permissive lists Examples Part 442 Definitions Constraints Examples ARM Short Form Constraints ARM Long Form Modules View (Mapping) Business Object Model (Entities, Information model definitions, EXPRESS-G) AP 214 ARM AP 203 ARM Mapping specification Part 28 configuration Definitions Objects Modules MIM Longform (implementable) Business Object XML schema (implementable) Compatible to OMG PLM Services Figure 2 Business Object Model and AM 442 Scope AP 242 compliant applications shall be able to exchange design structure with mechanical and composite contexts. AP 242 shall be extensible to cover upcoming new STEP extensions (e.g., 3D PMI "full semantic representation", 3D parametric, 3D Kinematics). AP 242 shall be consistent with ISO TC184 product data quality standards (part 59). Compliance with the STEP overall framework AP 242 shall be compliant with the list of other modular STEP standards (AP 233, AP 209, AP 239, and AP 210). Activity diagram AP 242 shall contain a generic activity diagram. The processes may be specialized by each manufacturer community, according to their needs and priorities in specific STEP Recommended Practices. V.: 1.0 Update:

25 Documentation AP 242 shall be fully documented, with generic examples or preferably concrete examples of automobile and aerospace allowing to ease the understanding by the users. Compliance with 3D visualization formats The formats for visualization may have different data models, but a documented mapping from the AP 242 data model shall be part of a 3D light visualization specification. Consistency with LT archiving AP 242 shall fulfill the requirements for LT archiving of aerospace and automotive product information. The upward compatibility of the information model shall be ensured (version management of the Long form of the ARM, AIM and the business object model). The aerospace industry, as contributors to the AP 242 project and of the LOTAR international project, shall be a sponsor for the configuration management in order to ensure the upward compatibility of the STEP modules. Implementation AP 242 shall allow for both MIM Longform and XML implementations on the business object model level. However, recommendations and rules are required, when which implementation form should be used. E.g., ARM for composite materials. Such recommendations shall be defined outside of the standard in AP 242 Recommended Practices (see below). AP 242 shall describe the implementation technology without any ambiguity. Example: the standard shall contain both the Business Object XML schema and the XML configuration specification. There shall be exactly one Part 28 configuration specification within AP 242. Currently for STEP modular APs, multiple different XML schemas are allowed and might be implemented. AP 242 shall use the concept of strong classification (as currently defined in AP 203 ed2 and AP 214 ed3, e.g. permissive list values for relation types) for clearly defined domains like geometry, or analysis. These kinds of classifications shall be explicitly defined in the standard. For product structure and other PLM/PDM type information AP 242 shall enable the use of an externally augmented classification built upon a framework template like ISO 22745, ISO 13584, or other RDLs. Figure 3 shows the implementation scenarios that shall be supported by AP 242. V.: 1.0 Update:

26 Manufacturer Supplier Data sharing on SOA basis ESB (AP242 XML + web services implementation form) ESB Long term archiving (LTA) RDL ISO ISO Conversion Quality check PDM 1 PDM 2 STEP AP242 PDM+CAD Offline Data Exchange CAD 1 CAD 2 Data consumer (information) Visualization (PDF, JT) 3D Model based design (without drawings) Web Client simple Viewer Supplier data exchange Figure 3 Implementation scenarios supported by AP 242 Recommended Practices Generic AP 242 recommended practices shall be developed, common to all types of industries. Example: update of existing CAD Recommended Practices, if required. Recommended Practices shall be coordinated and developed according to a joint procedure between the stakeholders of the AP. Common rules shall be defined for the use of an implementation form (Part 21 files conform to the AP 242 MIM Longform schema, XML files conform to the AP 242 Business Object XML Schema) as reference for the implementation, according to units of functionalities/modules/conformance options). E.g.: o CAD 3D with PMI exchange and LTA : MIM Part 21 o Composite materials exchange and LTA: Business Object XML o PDM now: exchange and LTA: MIM Part 21 o PDM future: exchange, sharing and LTA: Business Object XML V.: 1.0 Update:

27 Organization There is a strong need to set up a single international organization in charge of the coordination of AP 242 and of the associated common recommended practices. The organization model for the steering committee and for the procedure of coordination has to be defined. V.: 1.0 Update:

28 5 Scope of the proposed AP 242 Generally speaking AP 242 is the successor of AP 203 and AP 214. The new AP will replace the two existing ones. The user and vendor community of both existing APs would expect that none of the functionalities, which are currently defined in the two standards, disappear. Therefore the scope of AP 242 shall be at least the union of the AP 203 edition 2 scope and the AP 214 edition 3 scope. I.e. the first edition of AP 242 shall be a superset of AP 203 edition2 and AP 214 edition Functionalities both in AP 203 and AP 214 The following functionality is already covered by AP 203 ed2 and AP 214 ed3 and shall be retained in AP 242: Product / part / item (tool) Product management data (person, organisation, ) Product / item structure Document management External file reference Product / item properties Effectivity Work / change management Product / item classification Specification control 3D element structure 3D annotation 2D/3D visualization 2D geometry 3D wireframe 3D surface 3D BREP solid 3D CSG 3D GD&T 3D tolerance 3D surface condition 3D form feature User defined attributes 2D/3D drawing 5.2 Functionalities in AP 203 only The following functionality is contained in AP 203 ed2 only and shall be retained in AP 242: Catalogue Requirements 3D construction history 3D composite design Chemical substance Tabular measurement values V.: 1.0 Update:

29 5.3 Functionalities in AP 214 only The following functionality is contained in AP 214 ed3 only and shall be retained in AP 242: Cost calculation Process planning 3D kinematics Machining features 5.4 New functionalities Under the umbrella of AP 242 there are several functionalities with strong industry interest, which exist neither in AP 203 nor in AP 214 yet: 3D shape quality 3D parametric / geometric constraints design 3D kinematics assembly 3D GD&T at assembly level Sustainability information Access rights / digital rights management (DRM) Software / mechatronics 3D electrical harness 3D piping For 3D parametric / geometric constraints design, 3D kinematics assembly, and 3D shape quality already application modules exist which are candidates for inclusion into AP 242. Note: for 3D electrical harness, the success of AP 242 may result in the modularization of AP 212, taken into account the VDA KBL/VEC 13 specifications. More details on the proposed functionalities including AP 203 / AP 214 consistency analysis are listed in Annex A. 13 Kabelbaumliste (Harness Description List) / Vehicle Electric Container V.: 1.0 Update:

30 6 Migration strategy A strategy for the smooth migration to the new AP 242 has to be developed. Confusion of users and vendors arising from dealing with 3 APs (AP 203 ed2, AP 214 ed3, AP 242 ed1) should be avoided ( war of 3 popes ). There must be a clear message, that AP 242 replaces the APs 201, 202, 203, 204, and 214, There is no further development or maintenance on the old APs. I.e., they have to be frozen. The deprecation of AP 201, 202, and 204 is already proposed as the scope of these APs is covered by AP 203 edition 2. However, the message of a withdrawal after the publication of AP 242 to the outside market has to be considered. Implementations and products which claim conformance to AP 203ed or AP 214 ed3 must remain valid. V.: 1.0 Update:

31 7 Impact on complementary standards and applications This chapter outlines the impact of the convergent AP to complementary standards and applications. The complementary standards in focus are: OMG PLM Services SASIG Recommendation for cross company Engineering Change Management (ECM) NAS 9300 / EN9300 standard, for long term archiving and retrieval of 3D digital aerospace product information 3D light visualization specifications In each of the following sections a brief overview is provided, followed by the description of the dependencies and a discussion of potential impacts. 7.1 OMG PLM Services OMG PLM Services is a standard for sharing and exchange of product data in various application scenarios. It defines a platform independent reference model for supporting a variety of product lifecycle management services. This platform independent reference model consists of a so called Informational Model, specified using the XML schema notation, which is based on the AP 214 data model and a so called Computational Model which defines web services providing online access to the data and allowing internet based sharing and exchange scenarios. Version 2.0 is the current release of this standard. The Informational Model of OMG PLM Services 2.0 is derived from a subset of the ARM of AP 214 edition 3. The following Units of Functionality (UoF) of AP 214 comprise this Informational Model: S1 Product_management_data S3 Item_definition_structure S4 Effectivity S5 Work_management S6 Classification S7 Specification_control S8 Process_plan PR1 Item_property E1 External_reference_mechanism In total the scope defined by theses nine UoF contains 233 Application Objects. The Informational Model of OMG PLM Services itself is derived from these 233 AP 214 Application Objects using the so called configuration mechanism of ISO This configuration, defined in Annex L.2 of AP 214, specifies V.: 1.0 Update:

32 a generative mapping that produces an XML Schema containing an XML representation of the 233 Application Objects. This XML Schema is identical to the Informational Model of the OMG PLM Services. The following figure outlines the steps for producing the XML schema thus showing also the dependencies between AP 214 edition 3 and OMG PLM Services, V2.0 ISO , Annex K AP214 ARM EXPRESS ISO , Annex L.2 P28 Configuration ISO , XML representations of EXPRESS schemas and data, using XML schemas Mapping: AP214 ARM EXPRESS PLM Services XML Schema according to ISO , Chapter 10 produces ISO , Annex M XML Schema identical to Informational Model of OMG PLM Services Figure 4 Dependencies between AP 214 edition 3 and OMG PLM Services, V2.0 These dependencies imply that any change of the ARM portion of AP 214 in the areas mentioned above, e.g. during the course of developing the convergent AP, will directly result in a different XML Schema produced by the P28 mapping. If, on the one hand, modifications on the ARM Level of AP 214 caused by the convergent AP are moderate, it might be possible to modify the P28 configuration of annex L.2 in order ensure that the generated XML Schema remains identical to the Informational Model of the OMG PLM Services 2.0. On the other hand, if the ARM of the convergent AP differs considerably from the ARM of AP 214 edition 3 (e.g. modification of the data model structure, replacement of existing of introduction of new concepts), then it is likely that no P28 configuration might exists which is able to compensate the difference. In such a case, the development of a new version of the OMG PLM Services might provide a fallback solution. The border of the adaptability is determined by the power and possibilities offered by the P28 configuration options. 7.2 SASIG ECM Recommendation The SASIG ECM Recommendation provides a framework for the cross company engineering change management, thus enabling collaborating partners to communicate e.g. change request and change orders between their internal change processes and change management systems according to a defined ECM reference process with dedicated synchronization points and according to a well defined V.: 1.0 Update:

33 data model. Version 2.0 released mid of 2009 is the current release of this SASIG Recommendation. It relies on Version 2.0 of the OMG PLM Services and on the AP 214 edition 3. Currently the ECM Recommendation allows for three alternative possibilities for the representation of ECM data (implementation forms) within the cross company communication: EC XML Schema: an XML representation of the ECM Requirements Data Model that captures the information needs in the form of an end user terminology. Subset of the AP 214 ARM Data Model in EXPRESS: the elements of the ECM requirements data model are mapped to in total 60 Application Objects of the AP 214 ARM data model. OMG PLM Services: Through the mapping of the AP 214 ARM data model (see section 7.1 of this document) it is also possible to use OMG PLM Services for the communication of the change related data. The following figure depicts the derivation of the three alternative implementation forms from the ECM requirements data model. EC XML Schema ECM Requirements Data Model represented as AP214 ARM (subset) uses Annex L.2 of ISO PLM Services Informational Model (subset) representing the information requirements alternative allowed implementation forms Figure 5 Alternative implementation forms for ECM interfaces For those applications using the EC XML schema, no impacts caused by the convergent AP does exists, since this alternative is not bound to AP 214 / OMG PLM Services at all. Applications based on an AP 214 ARM implementation of the ECM protocol or of an implementation based on the OMG PLM Services are directly impacted by a potential modification of the AP 214 ARM V.: 1.0 Update:

34 caused by the convergent AP. The mapping of the ECM requirements data model to AP 214 ARM uses the following AP 214 eight UoFs and 60 Application Objects in total: S1 (17 Application Objects): item, item_version, design_discipline_item_definition, specific_item_classification, alias_identification, date_and_person_organization, date_time, date_and_person_assignment, person_organization_assignment, date, person, person_in_organization, organization, approval, approval_status, address, date_time_assignment S3 (3 Application Objects): single_instance, quantified_instance, next_higher_assembly S4 (2 Application Objects) duration, event_reference S5 (8 Application Objects): activity, activity_relationship, work_request, work_request_relationship, activity_element, project, project_assignment, project_relationship S6 (5 Application Objects): general_classification, classification_association, class_attribute, general_classification_hierachy, classification_system S7 (7 Application Objects): product_class, product_class_relationship, product_function, product_component, class_structure_relationship, product_structure_relationship, complex_product_relationship E1 (8 Application Objects): document, document_version, digital_document, digital_file, document_assignment, document_type_property, external_file_id_and_location, document_location_property PR1 (10 Application Objects): cost_property, mass_property, general_property, property_value_representation, string_value, simple_property_association, item_property_association, process_property_association, numerical_value, unit_component This implies that any modification, in the areas mentioned above, that results from the transition from the AP 214 ARM to the AP 242 BOM will result in a change of the mapping from the ECM requirements data model to the business object model of AP NAS 9300 / EN9300 standard, for long term archiving and retrieval of 3D digital aerospace product information The archiving of 3D design product information and making this information available in the event of product liability litigation poses a challenge not only with regard to regulatory restraints. The LOTAR project group develops a standard for the long term archiving of digital product data in the aerospace industry. The objective is to establish methods, processes and a data model for archiving of 3D design aerospace product information, such as CAD 3D with PMI and PDM information. The LOTAR project is a V.: 1.0 Update:

35 joint activity between the US and the European aerospace industries, under the supervision of the AIA and of the ASD Stan associations. The results of the project are the harmonized NAS9300 and EN9300 standards, respectively for the US and the European aerospace industies The LOTAR project group decided to organize the documents in different packages and parts (see Figure 6). Figure 6 EN9300 Part structure This modular based concept provides a higher degree of usability and adaptability. The packages are as follows: The Basic Parts provide an overview of the essential information on long time archiving and retrieval of 3D Design aerospace product information. The Common Process Parts define the main process steps of archiving and retrieval of 3D Design aerospace product information in a detailed and common manner. The Data Domain Specific Parts contain requirements and definitions for specific types of data related to long time archiving and retrieval. So far descriptions for CAD 3D with PMI model data and PDM data exist. The domain specific parts EN9300 1xx LTA of 3D CAD contain fundamentals and concepts of LTA of CAx, Explicit CAD Geometry, Explicit CAD Assembly Structure, Geometry, and Dimensions & Tolerance. Since these parts are AIM based (AP 214 CC2), no negative impact is expected. The domain specific parts NAS 9300 / EN9300 1xx LTA of 3D CAD contain fundamentals and concepts of LTA of CAx, Explicit CAD 3D Geometry, Explicit CAD Assembly Structure, Product and Manufacturing Information (PMI), including 3D Dimensions & Tolerance. Since these parts are AIM based (common to AP 214 CC2 and AP 203 ed2), no negative impact is expected. V.: 1.0 Update:

36 The domain specific parts NAS9300 2xx / EN9300 2xx LTA of PDM will contain fundamentals and concepts of Long term Archiving (LTA) of Product Data Management (PDM) data, PDM data from an "as designed" view, from an as planned view, and from an as delivered/maintained view. The first part, EN LTA of Product Management Data in an as designed view, is currently in an early stage of work. This document will probably be based on PLCS (AP 239 edition 2) and AP 203 ed2/ed3 or the convergent AP, with a requirement of consistency between these APs The remaining parts forming the PDM series of documents have not yet been started. But it is likely that they will also be based on PLCS, if the fist part of the PDM related parts is based on it. Because of this fact, there will be a task to ensure the compatibility with the convergent AP. 7.4 Consistency with ISO 3D light visualization specifications The suite of consistent STEP modular standards covering the full product life cycle and the main technical disciplines shall be the primary solutions for interoperability of PLM product information. As such, AP 242 standard shall be the cornerstone for interoperability of the CAD and PDM information, and the new ISO specifications for visualization of 3D light product information shall contain the mapping from the AP 242 information model. V.: 1.0 Update:

37 8 Risk management for the convergent AP With a project the size and complexity of AP 242, risks have to be expected in various areas. The following risks, the probability of them occurring, their severity, and the mitigation strategy are detailed below. For the probability and severity, the following abbreviations apply: L = Low M = Medium H = High Risk Probability Severity Mitigation Strategy Risk of large numbers of business objects and implementation models (for automotive, for aerospace, etc.) Lack of consistency for complementary standards such as OMG PLM services or OASIS PLCS services Technical Failure to map between AP 242 long form ARM and the business object model Possibility of an upward compatibility problem with the AP 242 AIM long form relative to the AP 214 edition 3 and/or the AP 203 edition 2 AIM Long forms Upward compatibility problem for the business object XML schema against the OMG PLM services V2 Lack of big picture for the relationship / complement between the STEP standards? Lack of compatibility of modular AP 233 and AP 239, with the detailed design modular APs, by difference in styles of modeling (explicit enumeration of classification vs. extendable classification capabilities by RDL) M M M L M M H H H M H M M M The team will have a strict rule to develop business object models for AP 242 The proposed architecture of the AP provides a solution for consistency with complementary standards Careful design of the business object model will ensure the mapping is possible 1) Correct the mapping 2) Correct the module 3) Raise a ballot comment against AP 239 DIS (Only in an extreme case) Bi directional mapping between both standards will be performed to ensure upward compatibility The AP 242 team will actively participate in the SC4 modules development activities The AP 242 team will raise comments against the AP 239 DIS and AP 233 DIS versions Careful consideration of technical alternatives V.: 1.0 Update:

38 Risk Probability Severity Mitigation Planning AP 242 not available in the time requested by stakeholders (timely availability of funding) Recommended practices for AP 242 not available for timely implementation Lack of AP 242 interface implementation by main PLM vendors Organization Unbalanced sharing of responsibilities and/or resources between aerospace and automotive industry, US, European, and Asian regions Unclear procedures for development and evolution of the convergent standards and recommended practices Lack of identification or acceptance of stakeholders of existing APs Problem with different cultures and/or communities coming together to create a convergent AP H H M M L M / H M H H H H M / H H H 1) The stakeholders will provide resources as required due to their commitment to the creation of the convergent AP. 2) Careful preparation of the project plan 3) Project management resources will be made available by committed organizations 1) Available resources from stakeholders will be made available for development of recommended practices 2) Most of the CAD recommended practices will only take minor updates 1) Timely involvement of IT vendors 2) Timely availability of recommended practices and sample files 1) committed joint ownership between the relevant international associations 2) Memorandum of Agreement between all committed organizations 3) Regular communication at the management and technical levels Committed joint ownership between the relevant international associations Committed joint ownership between the relevant international associations Regular communication at the management and technical levels V.: 1.0 Update:

39 Risk Probability Severity Mitigation Cost Lack of funding for development of the AP 242 Lack of funding for development of the AP 242 Recommended Practices Quality / performance Lack of quality of the documentation of the modular AP 242 H H M H M H 1) AP 242 development will not start until a minimum amount of funding is available 2) Committed organizations will pursue funding aggressively 1) AP 242 recommended practices development will not start until a minimum amount of funding is available 2) Committed organizations will pursue funding aggressively 3) Most of the CAD recommended practices will only take minor updates Every effort will be made to ensure the documentation for AP 242 will be of a high quality and understandable to the appropriate communities V.: 1.0 Update:

40 9 Project Plan 9.1 Project organization The project coordination should be shared by the US (PDES, Inc.) and Europe (ProSTEP ivip). A steering committee will be established with representation from the stakeholders. Only associations who contribute to the funding will become member of this steering committee. The following organizations have been identified so far: US International Europe Aerospace AIA ASD Automotive SASIG General PDES, Inc. ProSTEP ivip The technical tasks will be divided between working groups. Proposed working groups are: AP document and modules coordination Working Group Business Object Working Group PMI Working Group Other Working Groups Project coordinators set schedule, assign tasks to working groups, organize meetings, etc. V.: 1.0 Update:

41 ISO SC4 TC184 Project ISO Member Representatives Project Coordination Steering Committee Working Group Working Group Working Group Working Group Technical Experts Resources Representatives Participating Organizations Funding Contractors Figure 7 Project Organization 9.2 Financial principles The total costs (workload in person days, see 9.4) will be shared equally between the US and Europe. Each coordinating organization (i.e. PDES, Inc. and ProSTEP ivip) is responsible for its own costs. For version 1 of AP 242 the aerospace industry will bear the larger portion of the costs. A ratio of 65:35 is proposed. For the maintenance and subsequent versions of AP 242 an equal sharing of costs between the aerospace and automotive industry is proposed. The US funding will be managed by PDES, Inc. The European funding will be managed by ProSTEP ivip. Due to the different financing and funding models of the two organizations (for example, within PDES, Inc. member companies contribute with human resources) the resources requirement in this whitepaper are in terms of human resources, not US dollars or Euros. The funding of AP 242 will be organized within PDES, Inc. and ProSTEP ivip, rsp. Both organizations will provide individual budget sheets to their stakeholders. These budget sheets shall be based on the principles above and the organisation s funding model. The budget sheets are required by November 5 th, Deliverables The main deliverable is a new modular application protocol AP 242, and any associated new components of the ISO TC 184/SC 4 standards (modules, reference data, ). The project plan includes V.: 1.0 Update:

42 the delivery of NWI/CD document, its submission for CD and DIS ballot, and the resolution of any comments received. Besides the document itself Recommended Practices have to be updated and STEP interfaces tested. These tasks are part of the project, too. Set of modified application modules For AP 242 several modules have to be modified and new versions submitted to the Part 1000 maintenance process. The following modules are identified so far: 1001, 1003, 1004, 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1013, 1014, 1015, 1016, 1019, 1020, 1022, 1023, 1025, 1026, 1027, 1030, 1032, 1033, 1036, 1040, 1042, 1043, 1044, 1046, 1047, 1049, 1050, 1051, 1052, 1054, 1055, 1056, 1057, 1058, 1059, 1061, 1062, 1063, 1068, 1103, 1104, 1105, 1106, 1108, 1109, 1110, 1111, 1112, 1113, 1115, 1116, 1118, 1121, 1122, 1123, 1124, 1126, 1127, 1129, 1130, 1131, 1132, 1134, 1147, 1164, 1206, 1215, 1216, 1242, 1248, 1249, 1262, 1291, 1309, 1310, 1311, 1312, 1316, 1321, 1323, 1327, 1330, 1345, 1347, 1350, 1364, 1365, 1403, 1480, 1507, 1509, 1510, 1512, 1514, 1651, 1652, 1654, 1661, 1672, 1715, 1725, 1749, 1764, New application modules For AP 242 several new modules have to be created and submitted to the Part 1000 maintenance process. Modules for the following functional areas have already been identified: Form features (Machining features) 3D Kinematics Process planning Cost calculation Change PMI enhancements Sustainability 3D parametric / geometric constraints design (priority 2) 3D GD&T at assembly level (priority 2) 3D electrical harness (priority 3) 3D piping (priority 3) V.: 1.0 Update:

43 Part 442: The AP 242 main module For the AP itself, a new module has to be created, which includes among others the EXPRESS long form and global rules. Part 242: AP 242 The major parts for the new AP document are Scope Clause 4: Information requirements Clause 5: Module interpreted model Clause 6: Conformance requirements Annex: Activity diagram Annex: Business object model Annex: Mapping AP 214 ARM to business object model Annex: Business Object XML schema Annex: Mapping business object model to XML schema Supplementary material Improvement of the STEPMOD infrastructure The new concepts introduced by AP 242 (e.g. the business object model) require modification to the scripts, XSLTs, etc. provided on Sourceforge. Updated Recommended Practices The replacement of AP 203 and AP 214 by AP 242 has impact on existing Recommended Practices in the PDM and CAx area. The following documents need an update: CAx IF Recommended Practices SASIG PDQ Guidelines SASIG ECM Recommendation (priority 2) SASIG Assembly Data Exchange Recommendation OMG PLM Services Usage Guide (priority 2) PDM Schema Usage Guide VDA CC8 Recommended Practices on Variant Control Configuration (priority 2) V.: 1.0 Update:

44 9.4 Costs The costs are calculated on basis of the identified technical work. The technical work can be broken down in several categories. The following tables show the estimated costs in person days (PD). The tasks are prioritized according to P1: Modules, AP 242, Update of CAx IF and Assembly data exchange Recommended Practices P2: Parametric and assembly GD&T modules, update of remaining Recommended Practices P3: Wiring harness and piping Maintenance of the 1000 series The cost for the modification of existing application modules and the creation of new modules is based on an analysis of AP 203 edition 2 and AP 214 edition 3: There are 199 AP 214 application objects which will imply the modification of existing modules (definitions, examples, EXPRESS, EXPRESS G, ). There are 314 examples in the application object definitions. To identify and initiate the necessary work in the 1000 Parts, in summary 40 PD are calculated for this task: o 20 PD for issue documentation (bugzilla, etc.) o 15 PD for the documentation of modified modules o 5 PD for review and closing There are 72 modules identified which require modification. For each module, 1 PD is calculated. The inclusion of the functionalities which are currently exclusive to AP 214 require the creation of 14 new modules. For each new module 5 PD are calculated. Modification and creation of Application Modules (1000 series) Task Workload (PD) P1 P2 P3 Total Review and modification of existing modules Creation of new modules for AP 214 functionality Creation of new modules for AP 214 functionality STEPmod improvement Development of a navigation utility 5 5 Reviews V.: 1.0 Update:

45 9.4.2 Development of AP 242 and application module 442 AP 242 development Task Workload (PD) P1 P2 P3 Total Main clauses Annexes Supplementary material Reviews Update of Recommended Practices Update Recommended Practices Task Workload (PD) P1 P2 P3 Total PDM Recommended Practices CAD Recommended Practices Testing of STEP interfaces The testing of the STEP interfaces will be performed by the implementor forums within their usual test rounds. Therefore no additional costs are listed here Workshops Several workshops have to be planned for the project. E.g. Kick off meeting, SC 4 meetings, review meetings. The calculated costs are 56 PD Project Management For the project management 60 PD are calculated Total costs Total costs Main work package Workload (PD) P1 P2 P3 Total Modification and creation of Application Modules AP 242 development Update Recommended Practices Workshops Project management Figure 8 shows the distribution of costs with respect to the main work packages. V.: 1.0 Update:

46 Figure 8 Distribution of costs over work packages Priority 2 3 tasks represent a 20% of the total cost (see Figure 9). Figure 9 Distribution of costs in terms of priority V.: 1.0 Update:

47 9.5 Scheduling The project is divided in 5 main sections: work around the modules, redaction of the new AP (development of AP 242 and AM 442), definition of recommended practices, interface testing protocols, and project management. The overall project including ISO ballot, priority 2 and 3 tasks is 18 month. The pure development phase of the priority 1 tasks for the new AP242 ready for a first Ballot at SC4 is scheduled for 15 month after M0. Besides the logical dependencies between the different tasks two other factors that impact the project schedule have to be taken into account: 1) The availability of the resources. We are relying on a limited amount of human resources, around 10 persons, each of them having other activities in the time frame of the project. 2) The necessary iterations which will be needed to reach consensus between the AP242 stakeholders and also between the development team and the SC4 working groups (WG 3, WG 12). The schedule starts from the hypothesis that the work shall not be distributed over too many people to benefit from the best expertise through the whole project. It is suggested to consider having 4 main experts of AP203, AP214 and the modules architecture producing the real work + extra man power for the project management and some specific tasks. The workload is distributed among the experts to get monthly load between 35% and 75% on a single expert. To allow the consensus iterations reviews and approvals tasks are included at the end of each major section in the project plan. The review and approval tasks are concurrent with the end of the development tasks and extend the development tasks schedule by a few weeks/months. Milestones Starting with a M0 at project launch, the following milestones are on the critical path: M0 + 3mo: End of review of existing modules M0 + 3mo: Start of Business Object Model definition M0 + 7mo : End of redaction for main document scope, clause 4 and 6 M mo : Approval of modules modifications V.: 1.0 Update:

48 M mo : End of priority 1 new modules from AP214 M mo : End of Business Object Model definition M0 + 12mo : End of Express G schemas for 242 module M0 + 12mo : End of mappings between ARM and BOM, AIM and BO XML schema M0 + 12mo : Start of reviews and comments answers phase with stakeholders and SC4 M0 + 12mo : start of ISO ballot process M0 + 18mo : End of project Concurrently with these milestones, the other tasks are not on the critical path and have the following expected schedule Update of the priority 1 recommended practices from M0+8mo to M0+10 mo Update of the priority 2 recommended practices from M0+13mo Update of the CAx IF and PDM IF from M0+15mo to Priority 2 new modules development from M0+16mo The complete set of tasks is detailed in Figure 10. V.: 1.0 Update:

49 Figure 10 Project plan V.: 1.0 Update:

50 Regarding the costs distribution in time, the total amount of priority 1 tasks is scheduled between M0 and M0+15mo (see Figure 11). 9.6 Responsibilities Figure 11 Distribution of costs over time The following project coordinators are proposed: Phil Rosche, PDES., Inc. and Max Ungerer, ProSTEP ivip. The following table shows the responsibilities for the particular tasks: V.: 1.0 Update: