Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 Early implementation of ISO 10303-AP239 for product life cycle support Dr. Timothy M. KING ([email protected]), LSC Group, UK (HTTP://WWW.LSC.CO.UK/) 1. Introduction Starting in November 1999, the Product Life Cycle Support (PLCS) initiative1 has developed a draft for Application Protocol 239 (AP239), "Product life cycle support" as part of the International Standard, ISO 10303, "Industrial automation systems and integration – Product data representation and exchange". During 2003, the emerging draft of the standard ISO 10303-239 has been the basis for early implementation. In the face of various technical challenges, the initial three-year PLCS work programme [1] was not able to complete the necessary amount of effort to deliver a draft standard. However, the sponsors embarked on a further year of work, which has been successful in achieving the intended goals in the period from November 2002. The PLCS work programme ended on 31 October 2003. 2. Key features of AP239 2.1. Evolution of the ISO 10303 Application Protocol concept Although being another in the extensive series of Application Protocols that are constituents of the ISO 10303 standard [2], AP239 also embodies major features that are an evolution of the traditional form of an Application Protocol. These features are: • product as individual; • use of Application Modules [3]; • a limited number of Conformance Classes in the Application Protocol, while development effort has resulted in parallel delivery of Data Exchange Set specifications; • use of reference data. 2.2. Product as individual Product as individual is a concept within the AP239 information model. This concept is a major requirement for the Application Protocol because through-life support processes are often in the context of specific activities on specific planned or realised individual products (usually with an identifying serial number). In general, prior ISO 10303 Application Protocols have been about design and manufacturing specifications and, thus, the product concept is typical (with an identifying part number) rather than individual. ISO 10303 has not really dealt clearly with these contrasting requirements previously but AP239 has successfully delivered a more precise consideration of this issue. 2.3. Application Modules The successful ballot of four cycles of Application Modules for PLCS has shown that ISO 10303 has been able to embrace this significant new architectural approach. AP239 relies on a total number of 136 1 The sponsors have included: Aerosystems International; Alvis Hägglunds; BAE SYSTEMS; Boeing; Det Norske Veritas (DNV); Finnish Defence Forces; FMV; IFS; Lockheed Martin; LSC Group; Pennant; PTC; Rolls-Royce; Royal Norwegian MoD; Saab Technology; UK MoD; US DoD. © LSC Group 2003 Page 1 of 8 Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 modules. Already many of these modules also form part of other Application Protocols that are at various stages of progress towards publication. This common usage is the result of harmonisation between the different development teams and is an important basis for interoperability and re-use between implementations of the different Application Protocols. AP239 has a close relationship and shares common Application Modules with two specific Application Protocols: • AP203 (Edition 2), "Configuration controlled 3D design of mechanical parts and assemblies"; • AP233, "Systems engineering data representation". The close relationship arises from the complementary nature of the three Application Protocols in addressing the total life cycle of the product [see Figure 2.1]. In the case of AP203 (Edition 2), the shared modules are from the set of so-called "product data management (PDM) modules", which represent a core capability for the identification, description and structuring of component and assembly design. (Geometry is the main feature of AP203 that is not part of the scope of AP239.) concept a s l s a e s s o s p m is e d n design t includes geometry d e m e specification, o c i n v s r through-life update & tr e a s - upgrade ti n o i n manufacture concept concept a a s s l s l s a e a e s s s s o s o s p systems m p product m is e is e d n d n engineering t life cycle support t d includes requirements d includes support engineering, e e m m e engineering, architecture e configuration management, o o c c i i n n v v s s r definition, systems r resource management, tr tr e e a a s s - - ti analysis & modelling maintenance feedback ti n n o o i i n n manufacture manufacture Figure 2.1 Interaction between product life cycle support, design and systems engineering throughout the life cycle AP239 and AP233 share modules that cover the key areas of requirements, product breakdowns (including system, functional, physical, zonal and hybrid) and product interfaces. 2.4. Data Exchange Sets Traditionally, ISO 10303 Application Protocols have included a number of Conformance Classes that embody different subdivisions of the total information model and reflect a suitable scope for implementation within a software application. For example, AP203 includes Conformance Classes that cover different forms of three-dimensional geometry, such as wireframe and boundary representation [2]. These different geometries are alternatives and, thus, a single software application is not necessarily going to support all the alternatives. In the case of AP239, the scope of the Application Protocol is extensive, expressed at the top level as the four domain areas of configuration management, support engineering, resource management and maintenance and feedback [1]. The PLCS work programme has been unable readily to refine this top-level view into definitive Conformance Classes that are suitable for inclusion in the standard. In these circumstances, PLCS adopted an alternative approach that involves a greater emphasis on business analysis to determine the requirements for implementation of the Application Protocol. © LSC Group 2003 Page 2 of 8 Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 The PLCS approach has resulted in the concept of the Data Exchange Set (DEX) that describes the application of the AP239 information model within a bounded business scope. Teams have been working to refine Data Exchange Sets for scopes that currently include [4]: • fault states; • maintenance plan; • operational feedback; • product breakdown for support; • work package definition; • work package report. The refinement of the Data Exchange Sets is an on-going requirement that will depend on implementation of AP239 to highlight the applicability of the standard. Under these circumstances, the PLCS sponsors sought a mechanism by which to conduct follow-up work. A major requirement was for this mechanism to be less demanding and rigid than the contract-based PLCS work programme. The identified option has been to form a new PLCS Technical Committee [5] as part of OASIS2, which is a "global consortium that drives the development, convergence and adoption of e-business standards" [6]. The Data Exchange Sets will not be a formal part of ISO 10303. However, eventually, a set of stable Data Exchange Sets is likely to be the basis for an Edition 2 of AP239, whereby each DEX can become a Conformance Class within the standard. 2.5. Reference data Early in the genesis of PLCS, the information modellers began to recognise one major feature of the through-life support business domain. Prior Application Protocols have generally been definitive about concepts in the information model. These concepts appear as a specific entity (for example, "Product_version") and the associated attributes are identifying (for example, "id" and "name") or descriptive (for example, "description"). However, certain entity attributes have required the specification of valid or suggested instance values, typically if the attribute is a string. One example would be the set of suggested instance values for the method of determination for property values3. This set includes 'calculated', 'designed', 'estimated', 'measured', 'required', and 'set point' and appears in the relevant Application Module [7]. Such examples are relatively uncommon and, thus, have not raised the profile of one major issue in having the values within the standard: the listed values are not necessarily complete or applicable to all implementations of the Application Protocol. In the case of through-life support, lists of instance values are apparently more pervasive than in prior Application Protocols. Examples include qualifications necessary for different types of task, operating environments for products and failure probability level (when expressed non-numerically). Such values are important to the way that individual organisations perform business operations but no universally acceptable and comprehensive collection of required values is possible within the published standard (certainly not within any timescale that would meet the needs of industry). AP239 has embraced the concept of reference data in order to address the inflexibility of using the Application Protocol information model as a definitive specification to deep levels of detail. This concept depends on the Application Module "External class" [8], which extends the more fundamental capability of classification. The AP239 information model allows the user to classify the vast majority of data instances and, in each of these cases, identify the class as existing in an external library of classes. 2 Organization for the Advancement of Structured Information Standards. 3 The set applies to the value_determination attribute of the Qualified_property_value_representation entity. © LSC Group 2003 Page 3 of 8 Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 These external libraries then form the mechanism by which organisations can specify the meaning of and manage those classes. The information model places no restrictions on the potential choice of technology for the external class library.