PDM Enablers Version 2.0 RFP

1
PDM Enablers Version 2.0 RFP

• Presented to
• Object Management Group
• 16 November, 1999

Ed Tighe The Boeing Company
2
Standards-based Interfaces

• Design and develop an Interface Strategy based on
  OMG-PDM Enablers
• Partner with software vendor(s) to directly
  support standards-based interfaces
• Implement standard interfaces with PDM system and
  other strategic systems

Strategic Systems Links Through PDM Enablers

• Enovia/VPM
• MatrixOne
• Metaphase
• Sherpa
• UG/iMAN
• Windchill

Process Planning
PDM

• Defined Business Objects
• Request for Engineering Action
• Engineering Change Order
• Configuration Management
• Document Management
• Effectivity of Products and Occurrences
• Manufacturing Implementation
• Test, Maintenance, and Diagnostic
• Information

MRP
CAD/CAM
Other Strategic Systems
Other PDMs
3
Problem Statement

• The PDM Enablers (version 1) interfaces are fine
  grain (lower level) interfaces
• Application programmers have to manipulate those
  fine grain interfaces and traverse the
  relationships between them.
• This programming activity is usually tedious and
  complicated and each application programmer has
  to repeat them in each application.
• Manipulating fine grain interfaces and traversing
  the relationships between them also adds
  performance overhead when client applications
  send requests across the network to the servers
• To facilitate easy and efficient implementation
  and to satisfy required performance and
  functionality requirements for production
  implementation, there is a strong need to provide
  a set of convenience service interfaces to
  support those most often used complex PDM
  operations

4
Problem Statement - Cont

• Some of the often-used engineering concepts (BOM,
  Net Change, Drawing, Build-To Package, Technical
  Data Package, Note, etc.) and services
  (Event/Notification, Query capability) are not
  clearly supported in PDM Enablers (version 1)
• There is a strong need to provide a set of new
  interfaces to support there these concepts and
  services

5
PDM Enabler V2.0 Scope
PDM Enabler V2 Scope
OMG PDM Enabler Modules
Convenience Services
PDMResponsibility
Interface Part
PDMFoundation
Interface Software
PDMFramework
PDMDocument- Management
Interface Document
PDMProduct- StructureDefinition
Interface Drawing
PDMEffectivity
PDMChange- Management
Interface Model
PDMSTEP
Interface Note
Extensions
Interface EngChange
Notes
Other - TBD
Interface (Other)
6
Objective of Version 2.0 RFP

• Objective - The OMG PDM Enablers specification
  was adopted in April 1998. It exposes most
  PDM-supported objects in detail and provides
  "fine-grained" operations to manipulate those
  objects. This RFP solicits proposals to extend
  the adopted PDM Enablers to provide support for
  the following objectives
• Reducing complexity of client code
• Allowing server implementations to attain
  improved performance
• Increasing the scope of the PDM Enablers
  functionality (BOM, Net Change, Drawing, Build-To
  Package, Technical Data Package, Note,
  Event/Notification, Query capability, etc.)

7
Improve Performance and Complexity

• Service for Improving Performance and Reducing
  Client Complexity
• This type of services do not add any new
  functionality to the PDM Enablers, their main
  propose is to improve the system performance and
  reduce the complexity of client programming.
• Examples include
• convenience services for handing product
  structure and bill of material (BOM)
• convenience services for handling relationships
  between major objects
• convenience service for handling unique and
  recursive notes
• convenience services for handling
  check-in/check-out

8
Extend PDM Enablers Functionality

• Service for Extending PDM Enablers Functionality
• This type of services will provide some of the
  often-used functionality's which are currently
  lacking in PDM Enablers.
• Examples include
• services for query capability
• services for event service and notification
  service
• services for drawing-based systems
• services for tracking net changes
• services for built-to package and technical data
  package
• services for propagating effectivity
• service for handling variable and usage notes

9
OMG AB - Initial Concerns

• Question - Higher level abstractions over
  Existing PDM Enabler Spec
• Taking approach recommended on 4 - integrate
  newer functions into Version 1 Spec
• Question - Current requirements are not focused
  enough
• Have addressed this issue by ensuring solutions
  are not implied in requirement. Added words to
  make requirements more specific.
• Question - Is original specification being
  readdressed to take advantage of new technology
• Yes - with constraints of upward compatibility
  from Version 1
• Question -
• Section 6.2 seems to terminate prematurely.
• Section 6.5.5.1 seems to repeat section 6.5.4.2 -
  why?
• Similarly, section 6.5.5.2 repeats 6.5.4.4 - why?
• 6.5.14.1 interface for events - move the
  background text to the scope section - in my view
  discussions/background should not be in the
  requirements section.
• We agree with these points and have incorporated
  corrections.

10
AB Discussion - Monday

• General comment - Need to tighten up wording
  (primarily editorial problems)
• Need to ensure mandatory vs optional requirements
  are clear (also a PDM supplier concern)
• Need to ensure acceptance requirements are
  addressed explicitly (even if it says none
  required)
• Need definition for structured event types
• Other comments were primarily reiterations of
  previous slide
• General feedback was very positive and
  recommendation was to address specific concerns
  and present revised RFP to Architecture Board
  Thursday
• Wednesday PM is reserved for detailed review /
  revision of PDM Enabler V2.0 RFP
• Comments / Concerns???

11
Next Step

• Wednesday PM is reserved for detailed review /
  revision of PDM Enabler V2.0 RFP
• Comments / Concerns???