1. PLCS Data Model (The module hierarchy)
Application Protocol (AP) 239 – Product Life Cycle Support (PLCS)
PLCS Data Model
(The module hierarchy)

2. PLCS development 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 ref data libraries
Build on the 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
Activity, State, Product Structure
Encourage move towards a “single source” of Assured Product and Support Information (APSI)
Improved accuracy
Reduce duplication
Improved Configuration Management
Aim: to enable optimisation of support through life
PLCS Inc. (c) 2002

3. PLCS is a Modular STEP AP
ISO (AP239)
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 (ARM, MIM) and a mapping
More work – but eased by XML based environment for modules development (stepmod. sourceforge.net)
MIMs are based on common concepts used throughout STEP (Integrated Resources)
Full harmonization achieved where needed by using common modules
With CAD/PDM via PDM Modules and AP236 (214 based)
With Requirement Tools via AP233
PLCS Inc. (c) 2002

4. A Modular AP has two components:
Contents of Modular AP
A Modular AP has two components:
The Application Modules used by the AP
An AP document
PLCS Inc. (c) 2002

5. The Application Modules used by an Application Protocol:
The modules used by an AP provide the complete and unambiguous definition of the information model to be standardized
The module hierarchy within each AP shall have a single root module - the AP Module
The AP Module, and any subordinate module expected to support an implementation, shall include a long form EXPRESS of both ARM and MIM which resolve all EXPRESS 2 flexibilities (e.g. Select Types) and any conflicts or ambiguities in the EXPRESS rules inherited from lower modules.
Such modules shall be called Implementation Modules
The AP Module from one AP could be used as an Implementation Module within another AP
Application Modules will be published initially as ISO Technical Specifications
PLCS Inc. (c) 2002

6. The AP Document The AP Document serves four purposes:
It establishes the information model defined by the Application Modules as an International Standard
It provides further information on how the information model defined by the modules could be of value to business users.
It defines the Conformance Classes of the AP
It provides additional views of the information model defined by the Application Modules to support implementation (by html based indexing).
PLCS Inc. (c) 2002

7. Conformance Classes in a Modular AP
The adoption of the modular architecture does not change the role, nature or use of conformance classes with STEP
Conformance classes are defined in Section 6 of the AP Document (as now)
Within a Modular AP, a conformance class may be defined in two ways:
Either by declaring an Implementation Module to be a conformance class of the AP (in which case, every AO used by the Implementation Module shall be implemented by conforming applications)
Or by declaring the Implementation Module upon which the conformance class is based and listing the Application Objects that shall be implemented (as in a traditional AP)
Implementation shall be based on the specified subset of the relevant long form EXPRESS MIM.
PLCS Inc. (c) 2002

8. Application protocol publication
The AP document will be published with its full set of Application Modules as a single HTML document
The complete information model for standardization, as defined by the AP Module, will be will normatively referenced by the AP document
The detailed contents of the AP document, including the options for defining Conformance Classes, were confirmed by TC184/SC4 in San Diego (Mar 03)
Work is still needed to complete the XML architecture in STEPMOD to support the agreed contents (as of Mar 03)
PLCS Inc. (c) 2002

9. Conformance Classes and DEX
DEXs and Conformance Classes are equivalent concepts but have some minor differences
Data Exchange Set (DEX)
a PLCS, Inc. concept
A defined sub set of AP239 against which an implementer may claim compliance
Format set by PLCS, Inc rules
Will include usage guidance
A DEX could be published as a Conformance Class of AP239 IF:
The DEX is presented using the approved format for a CC
It is ready in time
Note: It may be possible to publish the related Usage Guides in Section 6 of AP239, or as an Informative Annex (yet to be agreed by ISO)
A DEX could be published independently (e.g. ODETTE) (or OASIS?)
Will include link to Reference Data
Conformance Class (CC)
an ISO/TC184/SC4 concept
A defined sub-set of an Application Protocol against which an implementer may claim compliance
Format set by ISO rules
Usage guidance (if any) is published separately
Published in Section 6 of an Application Protocol, as declaration of application objects to be used
PLCS Inc. (c) 2002

10. AP Documents, Modules and CC - Revised
AP2 CC5
Implementation module 4
(and AP Module for AP2)
Implementation module 2
Implementation module 3
UoF module
Foundation module
AP2 doc
AP1 doc
ARM LF.exp
MIM LF.exp
AP2 CC2
AP2 CC4
AP1 CC2
AP2 CC1
AP2 CC3
Implementation module 1
(and AP Module for AP1)
UoF module
Foundation module
Foundation module
AP1 CC1
ARM LF.exp
MIM LF.exp
(PLCS note: for CC read DEX)
PLCS Inc. (c) 2002

11. Introduction Legend PDM module PDM UoF module Ap239 Foundation module
Ap239 UoF level module
Ap239 Implementation module
AP Module
PLCS Inc. (c) 2002

12. UoF module: product_management_data
part and version identification
part view definition
product categorization
product identification
product identification assignment
product version
product version relationship
product view definition
PLCS Inc. (c) 2002

13. UoF module: document_management_data
document_and_version_identification
document_assignment
document_definition
document_properties
document_structure
external_item_identification_assignment
file_identification
PLCS Inc. (c) 2002

14. Enable “characterisation” of foundation modules
UoF module: management_resource_information
management_resource_information
alias identification
approval
certification
contract
date_time
date_time_assignment
identification_assignment
multi_linguism_arm
person organization
person_organization_assignment
project
security_classification
Enable “characterisation” of foundation modules
PLCS Inc. (c) 2002

15. UoF module: ap239_management_resource_information
alias identification
approval
certification
contract
date_time
date_time_assignment
identification_assignment
multi_linguism_arm
person organization
person_organization_assignment
project
security_classification
class
external_class
classification_assignment
attributre_classification
Enables “characterisation” & classification via Ref Data
PLCS Inc. (c) 2002

16. UoF module: ap239_properties
property_assignment
product_view_definition_properties
independent_property
independent_property_representation
value_with_unit
measure_representation
Extended_property_representation
PLCS Inc. (c) 2002

17. UoF module: ap239_document_management
document_management_data
ap239_management_resource_information
ap239_properties
Envelope
Message
Information-rights
PLCS Inc. (c) 2002

18. UoF module – requirement_management
management_resource_information
Requirement_identifcation_and version
Requirement_view definition
Requirement_view definition_relationship
Requirement_assignment
PLCS Inc. (c) 2002

19. Implementation module: ap239_part_definition_information
ap239_management_resource_information
product_as_individual
product_management_data
interface
ap239_document_management
interface_lifecycle
State_definition
ap239_properties
State_observed
requirement_management
PLCS Inc. (c) 2002

20. Implementation module: ap239_product_definition_information
product_breakdown
system_breakdown
assembly_structure
zonal_breakdown
part_definition_relationship
hybrid_breakdwon
product_replacement
functional_breakdown
product_view_definition_relationship
physical_breakdown
product_relationship
attachment_slot
ap239_part_definition_information
PLCS Inc. (c) 2002

21. PLCS Core: 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 doc) 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)
EF2000 PDM partners
.. A powerful and proven capability for Configuration Management of a complex product design
PLCS Inc. (c) 2002

22. PLCS Core: Life Cycle PDM Capability (2)
AP239 has added:
Classification, supported by external Reference data libraries
Product_as_individual (planned and realized)
Product breakdowns (system, physical, functional, zonal and hybrid)
Attachment_slot
Extended property capability
Interfaces
Message, Envelope (similar to ENGDAT)
Information Rights
Text base requirements (from AP233)
… A powerful capability (yet to be proven) for Life Cycle Configuration Management of Assured Product and Support Information
PLCS Inc. (c) 2002

23. Activity basics (and characterised)
Activity_characterised
Activity_method
Activity_method_characterised
work_order
work_order_characterised
work_request
work_request_characterised
ap239_management_resource_information
PLCS Inc. (c) 2002

24. Foundation modules: Activity Extensions
Activity_method
Activity_method_implementation
Scheme
Task_specification
State_observed
Work_output
State_definiton
Condition
PLCS Inc. (c) 2002

25. UoF module: Resource_management
Location
Required_resource
requirement_management
Location_assignment
Resource_item
ap239_product_definition_information
Type_of_person
Value_with_unit
Organisation_Type
Qualifications
Position_in_organisation
Experience
PLCS Inc. (c) 2002

26. UoF module: resource_management_characterized
Required_resource_characterized
Resource_management_characterized
Resource_item_characterized
alias identification
approval
certification
contract
date_time
date_time_assignment
identification_assignment
multi_linguism_arm
person organization
person_organization_assignment
project
security_classification
And CLASSIFICATION
ap239_management_resource_information
PLCS Inc. (c) 2002

27. Implementation module: AP239_task_specification_resourced
ap239_product_definition_information
AP239_Task_specification_resourced
ap239_mri
ap239_document_management
Required_resource
Task_specification
Condition
State_observed
Work_output
Condition_evaluation
State_definiton
Condition
Type_of_person
probability
Qualifications
probability_distribution
Experience
location
Organisation_Type
location_assignment
Position_in_organisation
justification
PLCS Inc. (c) 2002

28. Implementation module: Ap239_work_definition
Ap239_work_definitiion
Scheme
Activity
Resource_management
Product_as_individual
Activity_method
Individual
Type
Ap239_Task_specification_resourced
ap239_product_definition_information
Condition
Required_resource
Task_specification
PLCS Inc. (c) 2002

29. AP module: Ap239_product_lifecycle_support
Ap239_product_status_recording
Ap239_activity_recording
Observation
Product_as_individual
Ap239_work_definitiion
State_observed
Activity_as_realized
work_request_chr
ap239_properties
work_order_chr
Resource_as_realized
Scheme
Individual
Type
Ap239_Task_specification_resourced
Condition
Activity_method_chr
Ap239_product_definition_information`
PLCS Inc. (c) 2002

30. Activity domain - Express Schema Diagram (from MS Visio/Graphical Express)
PLCS Inc. (c) 2002

31. Implementing PLCS based solutions

32. Implementing PLCS
PLCS (a standardized information model) can be implemented in 3 ways:
As an integration architecture for a new product life cycle support management system (c.f. PIPPIN, EPISTLE, ISO 15926, NPDM)
As a mapping between systems (APIs) (LITS to RR CM system)
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
STEP has mainly been used to standardize data exchange
PLCS can also be used to promote further standardization via Reference Data (e.g. fault codes, skill grades)
PLCS Inc. (c) 2002

33. Implementing PLCS on 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
Less duplication – single assured source
Easy to present/deliver in any required form (e.g. Spec 1000D, XML, PDF)
Improved management of effectivity/applicability
Deliver a PLCS enabled maintenance management capability
Automatic upload from single assured source
The right data is available for maintainers (can be tailored to serialized item)
Improved feedback collection (report in the language used to specify, auto-complete)
Better in-service metrics
Faster learning
PLCS Inc. (c) 2002

34. Implementing PLCS for an existing program
Identify current information shortfalls or problems
Use the PLCS Activity Model to identify relevant data exchanges (arrows) that cross IT system boundaries, within and beyond your company
Implement appropriate DEXs, where there is a valid business case
Consider adopting PLCS for new data generated (changes, modifications, upgrades etc.)
N.B. 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 – abandon current systems (and standards) that meet business needs
PLCS Inc. (c) 2002