Early implementation of ISO AP239 for product life cycle support

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...
Author: Lilian Ramsey
0 downloads 0 Views 192KB Size
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:

2.2.



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. 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.)

e vic ser in-

de m ons tra tio n

dem o nst rat ion

includes support engineering, configuration management, resource management, maintenance feedback manufacture

e vic ser in-

manufacture dis pos al

ent

product life cycle support

ssm

ent

includes requirements engineering, architecture definition, systems analysis & modelling

concept e ass

ssm

dis po sal

dem o nst rat ion

e ass

e vic ser in-

ent

design includes geometry specification, through-life update & upgrade

ssm

concept

systems engineering

e ass

dis po sal

concept

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. Potential options include use of ISO 13584 [9] or ISO 15926 [10]. To use reference data in a given exchange, sharing or archiving scenario, an organisation specifies the required external class library to complement the AP239 information model. All partner organisations in the particular extended enterprise then adopt this class library in order to establish the expected populations of instance data that are to arise during information operations. Depending on the functionality that supports the external class library, manipulation and management of the reference data can be extensive and, thus, enhance the interoperability and analysis opportunities of the base data set that is in AP239 format. The need for reference data appears to arise because of one major factor. The early key successes of ISO 10303 have been in the area of geometry, where the mathematical nature of the domain is sufficient to provide a definitive basis for the content of the information model. The content of PLCS reference data is generally in respect of concepts that are not mathematically motivated. Instead, the required values are the result of human invention and, thus, fundamentally arbitrary. Different industrial communities have evolved specific terminologies and practices and, on this basis, no single collection of reference data is likely to be definitive for all possible implementations of AP239.

3.

Early implementation of AP239

3.1.

The motivation for early implementation

During the development process of AP239, the PLCS sponsors have grown to understand that the implementation of the standard is likely to be the most compelling evidence for the value of the Application Protocol. If an organisation has not been willing to make the initial investment in the development process then such a level of evidence is almost certainly necessary. Furthermore, the standard is also an engineering product that should be subject to testing before final confirmation is available as to fitness of purpose of AP239. In the light of the above, the early implementations have shown how AP239: •

can meet the foundational business requirements that motivated the development of the standard;



can meet the information requirements of the target business processes;



is feasible in the context of the available implementation technologies.

The following sections each address a business domain within the overall scope of product life cycle support. The number and diversity of these domains are significant in the light of the relatively short period over which the AP239 information model has been available. (The order of the following sections is of no particular significance.) 3.2.

Asset management

One of the very first PLCS implementations was the successful RB199 Demonstrator [1], which back in September 2001 gave an early confirmation of the validity of the deliverables from the PLCS work programme. The main business scope of the Demonstrator was asset management, which also includes the important aspect of having access to technical documentation that reflects the configuration of a given individual asset in the current state and, thus, improves the speed and accuracy of maintenance activity. 3.3.

Contractor logistic support

PLCS has an important role to play in the move to a situation where asset owners rely on contractors to provide logistic support services. In the case of this example of early implementation, LSC Group has helped both the supplier and owner of marine engines to understand the information requirements for a

© LSC Group 2003

Page 4 of 8

Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 potential regime of contractor logistic support. One major result has been to confirm AP239 is capable to support an electronic logbook replacing the current physical collection of information that accompanies the engine. The owner requires visibility of the support information and product history in order to avoid commercial lock-in to the contractor. The contractor requires access to operational feedback in order to provide appropriate support services. 3.4.

Support solution engineering

Defence Standard 00-60 [11] specifies the Logistic Support Analysis Record (LSAR) that provides a mechanism for extensive definition of support solutions. These solutions include identification of the logistically significant items within the product and specification of the tasks that are necessary to maintain the product. On behalf of the UK MoD, LSC Group has mapped all the elements of the LSAR to corresponding elements in AP239 (the LSAR consists of over 500 data element definitions). Beyond proving the utility of the standard, this mapping is also the basis on which to integrate support engineering information into the broader enterprise information context (that is, the UK MoD can view a total set of Logistic Support Analysis Records for all the different acquisition projects) and the Integrated Project Teams can bring the LSAR information into other applications that conform to AP239 (for example, a product data management or enterprise resource planning system). 3.5.

Work package management

The Unit Maintenance Management System (UMMS) implements the principles of reliability-centred maintenance into the UK Navy. This system includes computers onboard ship to control the daily activities of maintenance at sea. In addition, a shore-based system allows the Navy to collect together this information across the whole fleet. Meanwhile, the UK Government no longer owns a dockyard capability to perform repair and overhaul of Navy vessels. The privatised dockyards operate independent work planning systems and, thus, when a ship requires repair or overhaul, the MoD faces a data exchange problem to ensure that UMMS controls the work packages for the target dockyard. This situation is a prime target for which PLCS is an ideal solution. LSC Group has worked to produce a capability such that UMMS can generate work packages in AP239 format for distribution to the dockyards. This work has also demonstrated that XML is one of the viable representation technologies for use with AP239. 3.6.

Configuration management

In the case of configuration management, LSC Group has verified that PLCS provides all the necessary capability to represent the master configuration record of a submarine. This work is in the context of transferring information from the UK Navy Submarine Definition Database to the Vessel Material Planning system that operates at Devonport Royal Dockyard. AP239 can represent the complex Fleet Area Code that is a hybrid description of product structure using physical, zonal and system elements. 3.7.

Technical datum pack handover

Finally (in terms of this brief review of the early implementations), LSC Group has also looked at the situation where a Prime Contractor delivers a complex asset to the owner. Along with the physical product, the owner requires a large quantity of information. Typically, this information arrives in various formats and the owner faces a difficult challenge to gain a consistent and coherent view across the complete data set that consists of many different data items. LSC has developed a Product Information Explorer [see Figure 3.1] and demonstrated that PLCS is the basis for a capability to achieve this integrated view of the technical datum pack. The constituent information has included geometry (requiring integration of an AP203 alongside AP239, whereby three-dimensional models provide a rich level of detail to enable the maintenance engineer to plan and execute through-life product support), product structure, the LSAR and technical documentation. By presenting information in the context of defined product structures, the Explorer provides easy access to the breadth of content. Furthermore, the architecture recognises the diversity of available representation formats and can integrate sources that are databases, spreadsheets, traditional text-based files and XML files. Such a range is necessary for a typical complex asset.

© LSC Group 2003

Page 5 of 8

Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003

Figure 3.1 The Product Information Explorer interface for viewing product structures and attributes

4.

Future developments

Currently, the early implementations of AP239 represent a strong bias towards the requirements of the aerospace and defence sector. However, the PLCS development programme has always had the aim to create AP239 to be applicable to the through-life support of any type of high-value, long-life, complex asset. Such assets include power generation plants, oil platforms, manufacturing systems and commercial marine vessels. For the moment, the sponsors will concentrate on the situations where the vision of PLCS has taken root but as momentum grows, applications of AP239 will become more diverse. The current early implementations also avoid one major target for AP239: use of the information model as an enterprise integration mechanism. In this case, the extensive scope of the standard serves as a single whole to address the total business of through-life support. The UK MoD Defence Logistics Organisation (DLO) is a typical candidate for the implementation of AP239 as an enterprise integration model. The DLO has an overall mission to "sustain UK military capabilities present and future" [12]. Under pressure from the UK Government to control the total defence spend, the DLO has identified a strategic objective to change from a provider of support services (that is using military personnel and civil servants to perform support activities) to an intelligent decider (that is increasingly purchasing from commercial organisations support services that are faster, better, cheaper in a framework of managed risk). Such a far-reaching objective requires the DLO to have a clear view of enterprise performance and, thus, be able to understand the impact of top-level decisions on this performance. Enterprise performance is the subject of modern newspaper headlines, which regularly bring organisations such as the Ambulance Service or Network Rail to the attention of the general public, quoting performance figures such as emergency response times or average journey delays. Key performance indicators and the traffic light and corporate dashboard metaphors are prevalent in the attempt to provide the necessary indication of the extent to which an enterprise is succeeding. Enterprise performance has traditionally included financial health as a high priority. However, much financial analysis appears to provide answers in respect of profit as a measure of success. This narrow view is especially limited in the public sector, where decisions on funding levels are essentially arbitrary. In the case of the DLO, top-level performance crosses disciplines such as engineering and asset management and supply chain management. Individual systems within the DLO address these disciplines but a coherent enterprise view is not in place. Equipment availability is a typical performance

© LSC Group 2003

Page 6 of 8

Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 indicator that has key strategic interest. If the armed forces do not have access to key equipment because of failure of the through-life support processes then the DLO has a major case to answer. However, the analysis of enterprise performance is currently in need of a transformation to make more effective and efficient use of the disparate potential sources of data within the enterprise [see Figure 4.1].

the enterprise performance dashboard

e.g. asset availability = 75%

“cloud of magic transformation”

stove-piped data sources

e.g. asset availability = 75% business intelligence-driven analysis on the basis of an information model for enterprise integration

stove-piped data sources

Figure 4.1 Changing the approach to analysis of enterprise performance In Figure 4.1, the "cloud of magic transformation" represents the current approach to analysis of enterprise performance. The key features of this approach are: •

manual transfer of data from various sources into various analysis tools;



extensive human intervention to resolve the meaning of source data.

Transforming this approach is a major objective if enterprises are to be able to achieve major benefits through: •

use of a comprehensive, coherent information model for integration of data sources and analysis tools;



recognition that legacy data sources are vital because these systems often contain the foundational business processes;



a repeatable process that is auditable and subject to rigorous management;



removal of human subjectivity from the analysis and transformation processes.

PLCS addresses an information scope that corresponds to the primary business processes of the DLO and this is the basis for a plan to exploit AP239 to achieve the enterprise integration aspirations that are above.

5.

Conclusions

The architectural features of AP239 pose some shorter-term challenges as implementers learn how to deal with Application Modules, reference data and Data Exchange Sets. However, in the longer term, implementers will discover both that these features provide more robust traceability from the business

© LSC Group 2003

Page 7 of 8

Pre-print of paper for PDT Europe 2003, Manchester (UK) 25 to 27 November 2003 requirements to software application and that software code is more readily reusable between different implementations of AP239 and other related ISO 10303 Application Protocols. The early implementations of AP239 already address a significant range of the total scope of the draft standard and, thus, provide compelling evidence for this specific Application Protocol meeting the original business requirements that were the motivation for embarking on the Product Life Cycle Support initiative. When AP239 "Product life cycle support" meets expectations and becomes available as an International Standard during the course of 2004, the global engineering community will have access to an effective neutral solution to the challenges of exchanging, sharing and archiving product data for through-life support. Implementation of the standard will help owners and operators of complex, long-life, high-value assets to reduce the total cost of ownership of those assets. One major issue will be to extend the implementations beyond the current range of active applications that are mainly within the aerospace and defence sector.

Acknowledgements The author wishes to thank the keen support of staff at both UK MoD Product Data Standards HoS and LSC Group, including Margaret Christison, Martin Gibson, Mike Newton, Phil Rutland, Mark Pearson, Ian Sloss, Andy Richardson, Tim Turner, Les Debenham, Nigel Newling, Gordon Robb, Ann Meads, William Bowland and Rohit Sharma.

References [1]

King, T. M.: "Early practical realisation of Product Life Cycle Support", PDT Europe 2002, Turin, May 2002

[2]

"ISO 10303 STEP application handbook", Version 2, SCRA, 21 December 2001

[3]

"STEP module repository project", website

[4]

"dexlib", website

[5]

"OASIS Product Life Cycle Support TC", website http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=plcs

[6]

"Organization for the Advancement of Structured Information Standards", website http://www.oasis-open.org/who/

[7]

"Product data representation and exchange: Application module: Extended measure representation", ISO/TS 10303-1106:2003(E)

[8]

"Product data representation and exchange: Application module: External class", ISO/TS 10303-1275:2003(E)

[9]

"Industrial automation systems and integration -- Parts library -- Part 1: Overview and fundamental principles", ISO 13584-1:2001(E)

[10]

"Industrial automation systems and integration -- Integration of life-cycle data for process plants including oil & gas facilities -- Part 1: Overview and fundamental principles", ISO 15926-0001

[11]

"Application of Integrated Logistic Support (ILS)", Defence Standard 00-60 Part 0, Issue 5, UK MoD, 24 May 2002

[12]

"Strategic plan", The Defence Logistics Organisation, November 2002.

© LSC Group 2003

http://stepmod.sourceforge.net/ http://sourceforge.net/projects/dexlib/

Page 8 of 8

Suggest Documents