PLCS Template : April 2002

Download Report

Transcript PLCS Template : April 2002

Product Life Cycle Support (PLCS)
The Information Backbone to transform the Logistics Enterprise
The Benefits of PLCS
Howard Mason
Corporate IT Office
BAE Systems
Chair, ISO TC184 SC4 Industrial Data
Co-chair, OASIS PLCS TC
Chair, eBusiness MoU Management Group
The PLCS Initiative




The Business Context
 The key problem
Overview of PLCS
 Vision
 Approach
 Capabilities
 Status
Exploiting the benefits
Future plans
2
Setting the Business Context
Business Drivers



Reduced Cost of Ownership
 Users of products are seeking improved
availability, reliability, maintainability and
lower cost of ownership
Sustainable Business Growth
 Companies are seeking to make money
through the life cycle support of their
products to improve profits, improve
quality and be more competitive
Protect investment in product data
 Users of information systems want to
ensure long term usability for product
information as IT and processes change
3
Setting the Business Context
Digital Product Data has become a valuable business asset



New Business Opportunities
 Leading manufacturers are ‘going downstream’ to generate
additional revenue from supply of lifecycle support services
 Major users are seeking to outsource their support and information
services
Product Lifecycle Management
 Businesses are focusing on total cost of ownership, as product life
cycles increase and products become more expensive to maintain
 Increased focus on managing information throughout the product
lifecycle – Concept to Disposal
Extended Enterprise
 Increasingly complex business networks
 Not practical to adopt common system mandate
 Knowledge workers need to share information in real time
4
Setting the Business Context
Requirements of the Extended Enterprise

Extended enterprises are formed to meet
project specific requirements







Partners may differ from project to
project
Different partners are likely use different
systems
Companies want a common way to
exchange digital product data
Configuration Management becomes a
key enabler for information exchange
Suppliers want a unified approach from
Prime Contractors and OEMs
International collaboration demands
product data exchange and sharing
across many organizations
Worldwide operation demands a
worldwide standard
Program
Manager
Marketing
Product
Team 2
Engineering
Sales
Product
Team 1
Mfg.
Support
FIREWALL
Project X
Project Z
Project Y
Supplier A
Partner
Supplier B
Supplier C
5
Setting the Business Context
Configuration Management is a major challenge





Multiple product views
Major problems keeping
information to operate
and maintain a product
aligned to actual product
configuration through life
Major problems linking
support information to
product information
Inconsistent data
definitions
Software applications use
proprietary data
standards and are often
difficult to integrate
Customer
Requirements
Concept
and
Assessment
Demonstration
and
Manufacture
In Service
and
Disposal
As Designed
Configuration
As Manufactured
Configuration
As Maintained
Configuration
As Planned
Configuration
Feedback
Feedback
6
Setting the Business Context
Limitations with current standards
Current standards are specialized and focus on either:
 a piece of a business transaction or process, e.g. Order Part; or
 presentation of specific content, I.e. Aircraft maintenance manual
Example: Transaction oriented
 Defence: ASD 2000M (ex-AECMA)
 Commercial: ATA Spec 2000, EDIFACT, ANSI X.12, ebXML
Example: Content oriented
 Manufacturing and process centric:


ISO 9000, STEP
Operations and maintenance centric:


Defence: MIL-STD-1388, Def-Stan-00-60, ASD S1000D
Commercial: ATA Spec 2000, 2100
7
Setting the Business Context
Imagine the opportunities if …





Configuration management information
was always accurate, up to date and
immediately accessible
Maintenance information was precisely
tailored to the work to be done
Spares and inventory costs were
minimized through vendor involvement
in an integrated supply chain
In-service feedback was accurate,
meaningful and readily available to
product designers and support
managers
Change was easy to manage
8
Setting the Business Context
The Key Business Problem
How to keep the information needed to operate and maintain a
product aligned with the changing product over its life cycle?
Product
in Focus
Product Definition
Information
Transportation
Consumables
Maintenance
Schedules
Feedback
Tools
Software
Spares
Test
Equipment
Support
Facilities
Training
Storage
Requirements
9
Product Life Cycle Support (PLCS)
The stakeholders
Finnish
Defence
Forces
10
Product Life Cycle Support (PLCS)
The Initiative
A joint industry and government
initiative to accelerate development of
new standards for product support
information
An international project to produce an
approved ISO standard within 4 years;
ran from November 1999 – September
2003
PLCS is designed to ensure support
information is aligned to the evolving
product definition over the entire life
cycle
PLCS extends ISO 10303 STEP - the
STandard for Exchange of Product
model data
11
Product Life Cycle Support (PLCS)
Available capabilities - ISO STEP

STEP is an established international standard for the
exchange, integration and sharing of product data











Geometry
Product structure
Manufacturing interfaces
Drawings
Finite Element Analysis
Printed Circuit Assemblies
Wiring looms
Mechanical Design
Construction industry
Supports wide range of IT – ASCII, databases, XML, XMI,…..
Process modelling independent of information in EXPRESS
12
Product Life Cycle Support (PLCS)
STEP in service
Product Data Management exchange for Eurofighter
Supplier interface for Lockheed Martin
Configuration Management and Digital Pre-Assembly
exchange at Boeing - RR, GE and P&W
Interface between A380 and its engines
IBM's global e-procurement design data exchange
Solid model exchange for Electric Boat
US and UK Navy RAMP programmes
Japanese SCADEC programme for the construction industry
Ford CAD/PDM data integration
NASA Engineering information
13
Product Life Cycle Support (PLCS)
The Vision
Change
Directives
Standard
Commercial
Transactions
Scope of STEP Today
Product Structure
Product Representations
Product Performance
Life
Shared
Cycle
Data
Data
Support Performance
Quer
y
Maintain/Dispose
Use
Support Environment
Failure Analysis
Derived Disposable
Data
Maintenance Analysis
Task Resource Data
Support and
Operational
Feedback
14
Product Life Cycle Support (PLCS)
Extended Enterprise enabled by Internet technology
Customers Tier 1
Tier 2
Partners Suppliers Suppliers
Extended Enterprise of
OEM’s, Customer, Partners
and Suppliers
Product Lifecycle Management (PLM)
Enterprise Integration
through dedicated networks
Enterprise
Dept
Extended Enterprise Integration
Internet-based architecture and federated data models make possible
implementations involving thousands of users across many sites
PLCS
Domain
Domain specific
information systems
(e.g. CAD, MRPII, Planning)
Define and implement the support solution, maintain the product configuration
Concept
Assessment
Demonstration Feedback
Manufacture
Operational
Product Life Cycle
In-Service
Disposal
15
Product Life Cycle Support (PLCS)
Extended Enterprise – Importance of PLCS
Customers Tier 1
Tier 2
Partners Suppliers Suppliers
Enterprise
5 – 10 years
Typically 25 – 50 years Operational Life
PLCS Domain
Design for
Supportability
In Service Support and
Operational Feedback
Dept
Extended Enterprise Integration
When set against a timeline – the picture looks more like this!
C
A
D
M
In-Service
Product Life Cycle
D
16
Product Life Cycle Support (PLCS)
Typically complex systems environment – point to point integration
Operational
Objectives
CM Data
CM Data
CM Data
CM Data
Functional Requirements
5.
Requirements
Management
12
Depot Maint
Mgmt
9.
Product
Data
14 Defects
& Failure
Reporting
4.
Maintenance
Management
Defects
and
Failures
CM Data
Maintenance
Mgt Data
Support
Data
1.
Support
Data
7.
FMECA
LSA Data
3.
Stock
Mgmt
13.
Distribution,
Transportation
Design
Data
FMECA
Results
Support Data
Distribution
Data
LSA Data
6.
LSAR
8.
CAD
11
Parts
Supplier
Database
2.
Maintainers
Viewing
Tool
10
IETM
Part Data
LSA Data
Tech Pubs Data
Support Data
17
Product Life Cycle Support (PLCS)
PLCS will enable cost effective information exchanges
1.
Support
Data
Support data
2.
Maintainers
Viewing
Tool
Maintenance
Mgmt Data
3.
Stock
Mgmt
Part data
4.
Maintenance
Management
5.
Requirements
Management
6.
LSAR
7.
FMECA
Maintenance
Mgmt Data
Functional Req.
LSA Data
FMECA
Results
PLCS compliant information exchanges
Design Data
Design data
Tech
Pub Data
Parts Data
Maintenance
Mgt Data
8.
CAD
9.
Product
Data
10
IETM
11
Parts
Supplier
Database
12
Depot Maint
Mgmt
Distribution
Data
13.
Distribution,
Transportation
Defects
& Failures
14 Defects
& Failure
Reporting
In future, support system integration will be easier to implement
18
Product Life Cycle Support (PLCS)
Capabilities enabled by PLCS
Product Description
Capability to define product requirements and
configuration, including relationships between
parts and assemblies in multiple product
structures (as-designed, as-built, as-maintained)
Work Management
AP 239
Capabilities
Capability to request, define, justify, approve,
schedule and capture feedback on work
(activities) and related resources.
Property, State and Behaviour
Capability that describes and captures feedback
on product properties, operating states,
behaviour and usage
Support Solution and Environment
Capability to define the necessary support for a
given set of products in a specified environment
and to define support opportunity, facilities,
personnel and organizations
19
PLCS deliverables







A new vision for life cycle support
A terminology dictionary
An illustrative process model (AAM)
A large data model, standardised through ISO 10303-239
(STEP AP239)
Capability to define a set of data exchange specifications
(constrained subsets of AP239)
Improved capability to tailor or extend the data model or
exchange specifications using external reference data (e.g.
existing standards)
A standardised interface to transaction standards/systems
.. ebXML, Exostar, Covisint, S2000M – not achieved
20
PLCS – Activity Model




An IDEF0 model with 157 activities (boxes) and 220 information
exchanges (arrows)
Purpose:
 1999/00: to define the scope of PLCS activity
 2001/2: to expose data requirements
 2003: to represent the activities and information flows supported by
Application Protocol 239
Future use
 Communication the PLCS Vision
 Charting information exchange boundaries between organizations
 Identifying and illustrating DEXs
Available as .bp1, .idl, html, xml or pdf.
21
PLCS – Activity Model Concepts








The PIF – Product in focus: “what products do you want me to support?”
A PIF will be supported by one or more support solution definitions: how to support these
products
Each support solution definition is based on
 A deployment environment
 A support solution requirement
The deployment environment defines:
 A product group – a sub-set of the PIF needing tailored support
 A usage pattern
 A definition of the expected support organizations, locations, facilities and resources
A support requirement is a structured requirement statement including performance
metrics and targets for support performance
Support metrics are required to enable:
 Continuous optimization of support solution definition through life, based on
feedback from use
 Specification of an assessment strategy (what data to collect and how)
A PIF scope may include many deployment environments and hence many support
solution definitions
These will be derived from a common set of task and resource descriptions
22
PLCS – Activity Model Concepts

(Each) Support solution definition includes:
 Task specifications and task logic (e.g. diagnostic procedures)
 Relationship of tasks to the product configuration (including “effectivity”
/“applicability” to all product versions)
 Specification of task trigger conditions based on:



State of individual product (as identified by UID)
Usage of individual product
Prior task or other events
Identification and quantification of resources needed for each task,
including a resource consumption model
Task specifications may:
 point to an existing document
 point to an SGML document (e.g. an ASD S1000D Module)
 be fully “machine readable”
Task specifications may be linked to resources
 Required resources
 Resource items (products, people, facilities etc)



23
PLCS - APSI and Related Information



Assured Product Support Information comprises
 PIF scope
 Description of relevant deployment environments
 Support Solution requirements
 Product Definition Information (at least that needed for support)
 Support Solution Definitions
This full data set is subject to configuration change management
Related Information may comprise
 Test results
 Manufacturing records
 History of collected feedback on:



Individual product configuration over time
Product state and properties over time
Activities, including:
 Product use
 Work done
 Resource use
24
PLCS - Information modelling principles




Create a durable data model standard that can be
extended/adapted over time without re-modelling or re-ballot
 Identify key generic concepts and relationships
 Extend/adapt by classification and reference data libraries
Build on existing standards:
 PDM Schema and the STEP Modular Architecture
Accommodate values that change over time
 Support multiple values for the same property
 Support back-tracking & audit
Maintain unambiguous histories
 Product Structure, State, Activity
Aim: to enable optimisation of support through life
25
PLCS – The information model

Main concepts


A large, comprehensive data model
Defined in EXPRESS to facilitate integration with other
product data




Maps to multiple representation formats
EXPRESS-G graphical representation
153 Modules, ~500 Entities, ~1200 attributes
Can be extended using classification based on reference
data, stored in external libraries (RDL)

Built around OWL
26
PLCS is a Modular STEP AP




Modules allow common definitions of product data to be reused
Extensive re-use of PDM modules
 To bring compatibility with design/PDM tools
 Basic work order/work request process common to change in
design
Extended to provide
 Life cycle CM
 Full work management capability
 Condition based task triggers
All modules feature two levels of model, with mapping
 User view of information
 Link to common concepts across all of STEP
 Full harmonization achieved where needed by common modules


With CAD/PDM via PDM Modules
With Requirement Tools via Systems Engineering modules
27
PLCS enables requirement management through life

AP239 will share common modules with AP233 – Systems
Engineering (currently in draft):



Text-based Requirements
Multiple, related breakdowns, including “System” concept
Interfaces

Aim is to support requirements trace from pre-design
through to maintenance and disposal

UK MOD has funded demonstration project for this
capability with BAE Systems
28
PLCS provides full history to support optimization
and change over time

In the PLCS models it is assumed that any value supplied

E.g. a property such as mean time to perform a task
may have multiple values over time
where each value could have been:







supplied at different times
by different people
subject to approval
subject to security classification
Have an associated justification/probability/risk
This requirement has been recognised from the start of
modelling
Improve CM of support information by use of “single
source” Assured Product and Support Information (APSI)
29
PLCS - Life Cycle PDM Capability (1)

PDM Schema already supports automated exchange of





Part id and properties
Associated documents and files (incl. CAx)
Product structure
Product (and document) approval status
This is already in production use by



US Aerospace and Defence prime contractors (via AP203)
German/Swedish/French Automotive sector (via AP214 cc6)
Eurofighter Typhoon PDM partners
.. A powerful and proven capability for Configuration
Management of a complex product design
30
PLCS - Life Cycle PDM Capability (2)

AP239 has added:
 Classification, supported by reference data libraries
 Product_as_individual (planned and realized) - UID
 Product breakdowns (system, physical, functional, zonal and
hybrid)
 Text based requirements (from AP233)
 Extended property capability
 Interfaces
 Attachment_slot
 Message, Envelope (similar to ENGDAT)
 Information Rights
… A powerful capability for Life Cycle Configuration Management
of Assured Product and Support Information
31
Model overview
Information scope
What follows is a high level abstract view of the scope
showing key elements


From 10,000 feet!
And from 100 feet.
Used by Permission. Presentation Material Copyright Eurostep Group
32
Product
Product structures
Assignments
Part
Product _relation
related
related
relating
Product
View_relation
Version_relation
related
relating
relating
Product _version
of_ product
view_of
Product _view_definition
in_context
Context
Property
Representation
Classification
ID_alias
Person_or_
Organization
Date_time
Effectivity
Used by Permission. Presentation Material Copyright Eurostep Group
33
Types of Products
Requirement
Part
System
Breakdown
Functional
Breakdown
Product _relation
Interface
View_relation
Version_relation
related
related
relating
Product
Document
Slot
related
relating
relating
Product _version
of_ product
view_of
Product _view_definition
in_context
Context
Property
Representation
Classification
ID_alias
Person_or_
Organization
Date_time
Effectivity
Used by Permission. Presentation Material Copyright Eurostep Group
34
Product individual
State
Requirement
System
Breakdown
Part
Functional
Breakdown
Product _relation
Interface
View_relation
Version_relation
related
related
relating
Product
Document
Slot
related
relating
relating
Product _version
of_ product
view_of
Product _view_definition
in_context
Context
Product_individual
observed_ product
Observation
observed_state
actual_state
Product _individual_
version
State
expected_state
Planned_ Product
Property
Representation
Classification
ID_alias
Realized_ Product
Person_or_
Organization
Date_time
Effectivity
Used by Permission. Presentation Material Copyright Eurostep Group
35
Maintenance Plans,
Schedules, Job Cards,
Work Request/Order
Requirement
System
Breakdown
Part
Task
Functional
Breakdown
Product _relation
structure
Interface
Document
Slot
View_relation
Version_relation
related
related
relating
related
relating
relating
required_ product
Activity_method
Product
Product _version
utilizes
of_ product
view_of
Product _view_definition
in_context
Context
Product_individual
Scheme
method_used
observed_ product
Observation
structure
schedule
observed_state
actual_state
operates_on
Activity
Product _individual_
version
utilizes
State
expected_state
directive
start
Planned_ Product
Date_time
Realized_ Product
finish
start_state
end_state
Work_order
Property
Representation
Justification
in_response_to
Work_request
Classification
observation_consequence
Person_or_
Organization
ID_alias
Condition
Date_time
Effectivity
Skill
Used by Permission. Presentation Material Copyright Eurostep Group
36
Further details
Requirement
- Projects / Contracts
- Location
- Messages
System
Breakdown
Part
Functional
Breakdown
Interface
Document
Slot
handles
Project
Task
Product _relation
View_relation
Version_relation
has
structure
related
specifies
related
relating
Contract
related
relating
relating
required_ product
Activity_method
Product
Product _version
utilizes
view_of
of_ product
Product _view_definition
in_context
Context
Product_individual
Scheme
method_used
observed_ product
structure
schedule
Observation
storage
Location
observed_state
actual_state
operates_on
Activity
Product _individual_
version
utilizes
State
expected_state
directive
start
Planned_ Product
Date_time
Realized_ Product
finish
start_state
end_state
Work_order
Property
Representation
Justification
in_response_to
Work_request
Classification
observation_consequence
Person_or_
Organization
ID_alias
Condition
Skill
Date_time
Effectivity
Message
Envelope
Used by Permission. Presentation Material Copyright Eurostep Group
37
All PLCS
Used by Permission. Presentation Material Copyright Eurostep Group
38
PLCS - Reference data

What is it?




Values for attributes that are agreed and defined in advance
of use
E.g types of task, grades of people, types of products, types
of document
E.g. Nato Stock Number – classifications
Why use it?


Because it improves reliability and effectiveness of exchange
Because it can be extended:




To add to the scope of the standard
To provide project specific functions
Because it supports re-use of values from existing standards
Idea proven in Oil and Gas industry
39
PLCS – Data Exchange Specifications (DEXs)

DEXs are:







Subsets of the AP239 Information model
Selected to meet a specific data exchange need
Built from relevant modules
Supported by Usage Guidance, population rules and
Reference data
Can be refined from other DEXs
DEXs may be standardized at any level (work group,
company, project, organization, national, international)
DEXs enable


Consistent implementation of AP239
Data consolidation through time
40
DEX Architecture Overview
Business Dependant
Domain Independent
Concept driven
PLCS Exchange
Functionality
DEX
collects 1:?
Typical PLCS
functional units
Templates may be
hierarchically defined
through the use of
other templates
Functional unit
Instantiation
may be
subset of
Defined by
Capability
may refer to
functionality
defined in
Business DEX
collects 1:?
Business Object
represented by 1:?
represented_by 1:?
may be
represented_by 0:?
Template
contains 0:?
Business
Template
Business Driven
PLCS Exchange
Functionality
What to be exchanged
defined by Business
objects
Business Specific
Functional units
Business Templates
represent either the
object or one or more
object attributes
Business Specialised
Functional Unit
instantiation
41
Business DEX Architecture
Business Dependant
Business DEX
Collects 1:?
Business
Templates
represent either the
object or one or
more object
attributes
Scope
Introduction
Terms
Business overview
Information model
Business Objects
Dependent templates1
Business Reference Data2
Schema
[1]Note
that the current DEXlib format states
dependent capabilities.
[2]Note that the current DEXlib format states
Model reference data.
Business Object
Introduction
Scope
Business requirements
Information model
Business templates
may be represented by 1:?
May refer to
Template
Business
Template
Description
Model Diagrams
Input parameters
Reference parameters
Instantiation path
Instance diagrams
Characterizations
42
DEX Architecture
Business Dependant
Domain Independent
DEX
may be
subset of
Business process level
collects 1:?
collects 1:?
Capability
Business DEX
may refer to
functionality
defined in
represented by 1:?
Business Object
Business
information level
represented_by 1:?
may be
represented_by 0:?
Template
contains 0:?
Business
Template
Implementation Level
43
Current PLCS DEX developments









Product as individual
Product breakdown for support
Maintenance plan
Task set
Operational feedback
Fault states
Work Package Definition
Work Package Reporting
Plus a range of developments which apply additional
constraints and reference data based on generic DEX
44
Current situation (January 2007)







Activity Model published (available to all)
1750 requirements allocated to 153 modules
Modules published by ISO as Technical Specifications:
 PDM modules
 PLCS modules
 AP239 information model
Draft International Standard ballot for Application Protocol 239
successfully completed 13 September 2004, with unanimous
acceptance
Publication by ISO dated 1 September 2005, available as hyperlinked
CD-ROM product
Development of first eight Data Exchange Specifications under way
Implementation activities are gaining momentum in Norway, Sweden,
Finland, UK and US
45
Product Life Cycle Support (PLCS)
Unique Value Proposition





International Standard for product support information - based
on the ISO 10303 standard for product data (STEP)
Complete product lifecycle – from concept to disposal
Single source of assured product and support information
Data independence from Processes and Systems
Interoperability across enterprises and systems through:




Standardization of semantics for product support
Integrated suite of data models for data exchange and information
sharing
Utilization of ISO STEP standards, methods and tools
Extensibility and tailoring through the use of Reference data
libraries
Customers, Contractors and Software Vendors
working together to develop and implement
a neutral data exchange standard for product support
46
Exploiting the benefits
Implementing PLCS




The standardized PLCS information model can be
implemented in 3 ways:
 As an integration architecture for product life cycle
support management systems and information
 As a mapping between systems (APIs)
 As a standardized data exchange capability (plus
compliant software)
STEP technology supports all three and is language
independent (Cobol, Java, C++, XML)
STEP is in production use, with proven benefits, for
CAD, CAM and PDM systems
PLCS can also be used to promote further
standardization via Reference Data (e.g. fault codes, skill
grades)
48
Implementing PLCS for a new program


Use PLCS/STEP formats to capture design information as it
is generated in a way that support engineers can re-use
Develop Support Information in PLCS format




Deliver a PLCS enabled maintenance management
capability






Less duplication – single assured source
Easy to present/deliver in any required form (e.g. S1000D, XML, PDF)
Improved management of effectivity/applicability
Automatic upload from single assured source
The right data is available for maintainers (can be tailored to serialized item)
Improved feedback collection
Better in-service metrics
Faster learning
Identify DEXs for specific exchange requirements
49
Implementing PLCS for an existing program





Identify current information shortfalls or problems
Use the PLCS Activity Model to identify relevant data
exchanges that cross IT system boundaries, within and
beyond your company
Implement appropriate DEXs, where there is a valid
business case
Identify new DEXs if required (business, company, national
or sector level)
Consider adopting PLCS for new data generated (changes,
modifications, upgrades etc.)

Most current formats can readily be delivered from a PLCS integrated
source. The latter is cheaper to build and easier to maintain.

What NOT to do – immediately abandon current systems
(and standards) that meet business needs
50
Benefits from data quality




PLCS provides standardised rules and relationships for
information
Converting to standard form will reveal many of the
inconsistencies in existing information sets
Need to apply resources to cleanse existing data
MUCH cheaper than discovering errors later!
51
Current implementations



Visby Corvette
Gripen pilot project
Norwegian frigate





Eurostep Share-A-Space
BAE Systems Land Systems Hagglunds
UK MOD pilots for RAF LITS and Navy UMMS


Extending to other NDLO programmes
Being promoted actively for JSF
Logistics Coherence project
US DoD ELITE project for UH-60 helicopter


Extending to other service linked to UID
Plans for HMMWV and Bradley
52
Future Plans
Standards development and maintenance






ISO TC184/SC4 is responsible for “Industrial data”
Working Group 3 is responsible for “Product modelling”
Team 8 is responsible for “Product life cycle”
Team 8 will retain responsibility for AP239
Resources committed through national standards bodies
Also provides active liaison to Systems Engineering
development
54
DEX Development and publication








Open-source infrastructure developed
Seeking more open participation
 lower cost entry
Need enhanced links with other information standards
development
Selected OASIS consortium as parent
Formed OASIS Technical Committee for “Product Life
Cycle Support”
Open to all OASIS members
Operating under OASIS rules
Depends on resources contributed by participants
55
The OASIS Technical Committee

The purpose of the OASIS Product Life Cycle Support TC is
to:





establish structured data exchange and sharing capabilities
for use by industry to support complex engineered assets
throughout their total life cycle
define, develop, test and publish OASIS Product Life Cycle
Support DEX’s based upon ISO 10303 (STEP) Application
Protocol 239 (Product Life Cycle Support).
liaise with ISO TC 184/SC4
coordinate with relevant OASIS Technical Committees
promote the use of OASIS Product Life Cycle Support DEX’s
across industries and governments world-wide
56
The way ahead

The PLCS consortium has delivered the basic standard,
and an infrastructure for exploiting it, and has closed down

Join in an early implementation
Join the OASIS Technical Committee to participate in DEX
development



See www.oasis-open.org and select PLCS
Contribute to further developments in ISO through your
national standards body
57
PLCS: Relationship to other standards
“If I have seen further,
it is by standing
on the shoulders of giants.”
(Sir Isaac Newton)
58
PLCS: Relationship to other standards
POSC/
Caesar
EXPRESS
based
Mil Spec
2549
Def Stan
Def Stan
00-60
00-60
Logical
RCM
IT
AP208
Mil Spec
1388
TC184/SC4
WG3/T8
PWI
FMV
CTG2
PLCS
STEP
NCDM
AP203
AECMA
1000D
2000M
SGML
EDIFACT
ATA
Effectivity
PDM
Schema
OMG
AP 233
PLIB
ISO
15288
59
PLCS: Relationship to other standards

Current position


The opportunity




PLCS can use the data generated by current ILS standards
PLCS can enable much higher levels of data integration
PLCS, and other factors, will drive change in most current ILS
standards
The pace and direction of this change depends on market
factors
The challenge

To exploit the development of PLCS to deliver improved
logistics services and capabilities
60
Product Life Cycle Support (PLCS)
The Information Backbone for the Enterprise
Questions?
Answers!