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 (TMK@LSC.CO.UK), 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