1 proposed plcs tc organization and functional responsibilities revision 2 050210

1

Proposed PLCS TC Organization and Functional Responsibilities

Revision 2 050210

2

Agenda

• PLCS TC Organization and Participants

• Hierarchical Functional Responsibility

3

OASIS TCChairSecretariat1 Voting Member per CompanyTechnical LeadImplementers Forum Lead

PLCS TC Organization and Participants

Technical OversightLead (Information Architect)2 Tool Experts2 Business Experts

Secretariat1 Secretariat

Quality AssuranceLeadTesters

Pilots/ProjectsNorwegian PilotUK MOD PilotSwedish PilotOthers

OASIS TC Management

Technical Development Oversight for DEX, Capabilities, and Reference Data and other documentation

Related, independent Projects/Pilots established for a business need. Efforts are shared with PLCS TC

Ensures material submitted for OASIS balloting meet requirements. Works closely with Implementers Forum

4



PLCS TC Organization


DEX Development Teams

1 Team Lead 1 Modeler 1 Business Expert

Implementers ForumLeadSoftware Product VendorsImplementersIntegrators

Infrastructure / Tool Team

Information Architect1 Tool Expert


Pilot/Project Test Runs


DEX 0 Development Team



DEX X Development Team

DEX Y Development Team

Reporting

5

Organization Functionality – OASIS TC

• Publish AP239 as IS• Monitor and Maintain AP239

• PLCS TC Administration

• PLCS TC Work Programme Management

• Balloting within PLCS TC

• Publishing within OASIS

• Communications

• Marketing OASIS TCSecretariat1 Secretariat

ChairSecretariat1 Voting Member per CompanyTechnical LeadImplementers Forum Lead

6

• Provide Technical Oversight for DEX, Capability, and Reference Data Development

• Establish and maintain documentation• Review DEXs, capabilities and reference

data

• Harmonize with established SC4 and related standards

Organization Functionality – Technical Oversight


7

Organization Functionality – DEX Development Teams

• Develop Capabilities

• Develop DEX Packages

• Develop Reference Data

• Develop Rules




8

Organization Functionality – Infrastructure/Tool Team

• DEXLib Infrastructure

• DEX specification template

• Reference Data Library Infrastructure

• DEXLib Tools


Infrastructure/Tool Team Information Architect1 Tool Expert

9

Organization Functionality – Quality Assurance

• Establish Quality Framework

• Establish and Liaison with Implementers Forum

• Ensure submissions meet requirements for OASIS Balloting

• Verify and Validate DEX Team Testing


10

Organization Functionality – Implementers Forum

• Testing

• Reuse of solutions

• Review and recommend changes



11

Organization Functionality – Pilots/Projects

• Establish DEX Development Teams under Technical Oversight

• Establish Pilot Test runs with Implementers Forum

• Development of non-OASIS documentation

• Share results and lessons learned


12


PLCS TC Organization Summary





• Publish AP239 as IS• Monitor and Maintain AP239• Balloting within PLCS TC• Publishing within OASIS• PLCS TC Administration• PLCS TC Work Programme Management • Communications• Marketing

• Provide Technical Oversight for DEX, Capability, and Reference Data Development• Establish and maintain documentation• Review DEXs, capabilities and reference data• Harmonize with established SC4 and related standards

• Establish DEX Development Teams under Technical Oversight• Establish Pilot Test runs with Implementers Forum• Development of non-OASIS documentation• Share results and lessons learned

• Establish Quality Framework • Establish and Liaison with Implementers Forum• Ensure submissions meet requirements for OASIS Balloting • Verify and Validate DEX Team Testing

14


• Monitor and Maintain AP239– Implement change programme – Monitor SC4 modules for input on AP239– Submission of change requirements to SC4

OASIS TCSecretariat1 Secretariat


15


• PLCS TC Administration– Meetings and conference calls– Identify potential future DEXs– Develop Business Ontology– OASIS exploders

– OASIS PLCS TC Website

– Administration of DEXs, capabilities, reference data, documentation tool through the ballot process



16


• Balloting within PLCS TC– Rules for approval of methods– Agree process for review / ballot / update /

maintenance of technical documentation – Review DEXs and Reference Data submitted

for OASIS standards– PLCS TC balloting, OASIS balloting,

publishing and regular reporting to OASIS members



17


• Publishing within OASIS– Procedures for publishing

• Agree with OASIS how the DEXs are to be published, i.e. what format.

• Agree with OASIS how to publish Reference data

– Publish• DEXs as OASIS standards• Core PLCS Reference Data• Business domain extensions as standardized extensions to

PLCS Reference Data



18


• PLCS TC Work Programme Management– Agreed programme of work– Establish resource requirement – Agreed prioritization of tasks and resources– Agreed allocation of programme tasks– Establish and maintain a detailed project plan– Manage activities described in the project plan

• Recommend additional activities• Identify actions relevant for the OASIS TC scope

– Track progressOASIS TC



19


• Communications– SC4 AP239 relevant working groups– OASIS PLCS Teams– Implementers Forum – Pilots/Projects

• Marketing– Promotion – Maintain library of success stories– Maintain library of presentations for PLCS member

reference– Outreach needed to spread word on PLCS value



20

• Provide Technical Oversight for DEX, Capability, and Reference Data Development– Administer the Technical Development work programme– Establish a standardized, stable Business Ontology for PLCS– Consolidate existing Reference Data files to establish baseline core– Agree DEX and Reference Data development processes– Establish API for PLCS– Specify a representation of a thesaurus of business concepts

reflecting business terms

– Incorporate the recommendations from the series of DEX Sync Workshops

– Agree how Reference Data will be maintained– Develop Rule types for DEXs and capabilities

Organization Functionality – Technical


21

• Establish and maintain development documentation guidance– Format and content– Rules– Guidelines– Capabilities, Data Exchange Sets, and Reference Data– Mapping– Testing and Test documentation– Business Concepts– Translators– Conformance Guidance/Requirements



22

• Establish and maintain usage documentation guidance

– Business user guidance

– Software implementer guidance

– Contract managers guidance– Specialisation pruning of DEXs



23

• Review DEXs, capabilities, and reference data– Reduce duplicate development and improve

interoperability

– Ensure submissions meet OASIS ballot requirements

– Harmonization within PLCS TC of • Reference data• Interpretations / mapping solutions• Translators • Mappings• Projects

– Impact of SC4 module changes on DEXs



24

• Harmonize with established SC4 and related standards– Harmonisation with SC4 standards

• 10303 STEP APs• 13584 PLIB• 15926 Oil & Gas

– Harmonisation with other standards• ASD (AECMA) 1000D and 2000M• MIP• OAGIS 9 • OMG• SCORM• UK MOD 00-60• W3C



25


• Develop Capabilities

– Develop new capabilities as required– Enable representation of instantiation

capabilities– Set up a review structure for

capabilities




26


• Develop DEX Packages– Develop DEX Documentation

• Develop Implementation options• Capabilities• Business concepts• DEX Documentation• Reference data• Prune of long forms

– Develop a ‘core’ capability set– Initial testing using DEX developed test data– Re-develop initial set of DEXs i.a.w. common agreements– Incorporate new Reference Data




27


• Develop Reference Data

– Populate RDL services– Propose reference data from pilot sources– Instantiate reference data– Link with other standards– Develop a programme to monitor the

resolution of ballot comments• Develop Rules




28


• DEXLib Infrastructure

– Develop the DEXLib architecture and a framework explanation

– Enhance user friendliness– Indexing mechanism

• From the Business Concepts to DEX capabilities• From terminology dictionary to DEXlib

– Develop Thesaurus Tool for extracting semantics/definitions – Expand the introduction to DEXLib – Extend existing DEXLib functionality to activate and complete scripts

with information– Develop template for exchange agreements as part of each specific DEX

– DEXlib publication environment



29


• DEXLib Infrastructure (cont’d)– Continue to maintain DEXLib on Source Forge

• Maintain an HTML mirror of DEXLib for non- developers• Allow an XML view facility in browsers (other than Internet

Explorer)• Extend DEXLib to allow HTML publications• Extend DEXLib to allow individual (or sets of) DEXs to be

published as a standalone package electronically and on paper



30


• DEX specification template

– Develop an agreed DEX template for acceptance by OASIS based on the example DEX “Assembly part list” to DEXLib



31


• Reference Data Library Infrastructure

– Define reference data architecture– Establish a PLCS web server – Develop Pilot RDL service– Agree and standardised RDL services– Develop industrial strength RDL services– Define management of RDL services – Publish OWL files on the PLCS Web server– Establish PLCS RDL server accessed via APIs from translators– Establish a better development environment for reference data

consolidation and management– User-friendly interface to reference data library from DEXLib



32


• DEXLib Tools

– Develop and maintain tools supporting DEX, Capability and Reference Data development

• Tools for the revised DEX architecture containing– business concepts– specializations of generic capabilities and DEXs– rules

– Establish tools to develop / view the test data and validate test results– Tool for Work Progress tracking in DEXLib– Tool for converting existing Part 28 file to Part 21 file– Extend DEXlib tool set

• User friendly front end• Develop terminology dictionary• Interface to reference data• Allow publication of DEXs and Reference Data

– Develop templates for main rule types– Develop scripts for business concepts, using rule templates



33

Organization Functionality – Quality Assurance

• Establish Quality Framework – Review Framework for Quality – Editing and approval of DEXs

• Establish and Liaison with Implementers Forum

• Ensure submissions meet requirements for OASIS Balloting

• Verify and Validate DEX Team Testing


34


• Testing

– Define new or identify existing industrial strength test data

– Develop implementer’s test tools– Test DEXs – Test interoperability by round robin test rallies

• Reuse of solutions

– Establish library of “Lessons Learned”



35


• Review and recommend changes

– Capabilities, DEXs, and Reference Data– Business concepts– Harmonization

• Establish guidelines for the implementers• Raise harmonization issues and recommend

changes for– Capabilities, DEXs, and Reference Data– Interpretations / mapping solutions– Mappings– Projects/pilots– Translators



36

Organization Functionality – Pilots/Projects

• Establish DEX Development Teams under Technical Oversight

• Establish Pilot Test runs with Implementers Forum• Development of non-OASIS documentation

– Capabilities, DEXs, and Reference Data– Guidelines

• Share results and lessons learned– Implementers Forum– OASIS TC– Other DEX Development Teams– Quality Assurance– Technical Oversight


37

Measures of Goodness

• Develop a data exchange template – A "data exchange contract" shall require

• Identification of the specific DEX(es) that shall exchange the business data – to enable conformance testing

• Identification of standards used, and the resulting usage of reference data

– Involved parties need to agree what is their recognized identifier. A text shall be added in the exchange agreement to note the “preferred” option as the one to be used for globally unique identifiers, e.g. for identifiers that may be used for data merge.

• Reference Data Library– Class of class definitions in PLCS/OASIS RDL may be needed for

contracting purposes. How to define class of class in OWL shall be investigated

– Separate OWL project files shall be defined for representation of specific projects and their local terms

• Develop DEXs for business implementation

38

Measures of Goodness

• Input recommendations from the synchronisation workshops• Rules shall be uniquely enumerated (in capabilities etc) to allow

normative reference to them• Rules shall be placed at the lowest possible level, i.e. in

capabilities, without mandating PLCS global rules. Experience will show where the lowest level is.

• Expand the introduction to DEXLib. Shall include information as– Data exchange architecture– Reference data– Global identifiers– Rules

• Graphical presentation of information in DEXLib shall be considered

• User-friendly interface to reference data library from DEXLib – Graphical representation of reference data hierarchy HTML

version

1 proposed plcs tc organization and functional responsibilities revision 2 050210

Documents

team lead

tool experts

business experts secretariat

implementers forum slide

agenda plcs tc organization

proposed plcs tc organization

plcs tc publishing

tool expert slide