70 likes | 79 Views
Norwegian PLCS pilots. Experiences and Reflections 3rd February 2004 Leif Tonning, DNV. Some alternative process ambitions. Point to point exchange from one legacy to another – effective for exchange between two parties – PLCS is not needed
E N D
Norwegian PLCS pilots Experiences and Reflections 3rd February 2004 Leif Tonning, DNV
Some alternative process ambitions • Point to point exchange from one legacy to another – effective for exchange between two parties – PLCS is not needed • Point to point exchange using generic and powerful data resouces subject to precise interpretation – PLCS facilitates standardization of the exchange • Automatic data exchange between legacy systems, globally – PLCS is only one step on the way
Where is PLCS in the process? • Product Life Cycle Support – quite an ambition • The activity model does provide a common understanding of what to do, why, and how • The PLCS data model provides a very powerful resource for exchange of support data between legacy repositories – after interpretation • PLCS does not provide a finite data dictionary to support common interpretation of business data – as needed for finite size translators
Table contents of source legacy: Ship class Ship identification code Ship name Ship hull number Building Shipyard Keel laying date Launching date SAT start sate Delivery date End Warranty date A receiving legacy application: Product group 1 = Materials Product group 2 = Equipment Product group 3 = Functional Location One start date is allowed – date type becomes ”hard wired” Other dates may be assigned using Classification ”Launching date” may be selected as ”Start date” An view of legacy data – the challenge
Steps in the data exchange process • Document the interpreted source data terms and contexts according to PLCS data model rules • Facilitate coding of the PLCS representation, quality control of the data, and reuse of results • Document the data mapping algoritms • Coding – enabling population of the data model • Pack and unpack a P21/P28 file for data transfer – queries and ”filters”/templates to enforce the context • Personally, I am not convinced of the selected PLCS DEX concept • Translate the interpreted source data terms and contexts for a receiving legacy application • Populate the receiving legacy • Reverse the process
Techniques used in the Norwegian pilots • Instantiation diagrams – example NDLO-P1-02 - Individual frigates, their class and breakdowns (could be a DEX) • The generic Capability CAP_013 - Date assignment (PLCS business term!!) • The specific Capability CAP_013_1 - ship launching date (our legacy business term!!) • Document: Instantiation of contractor legacy data in the PLCS data model – a user guide - potentially useful should a common business terminology be agreed
Reflections • PLCS does the job, but costs are still high • A common data vocabulary that defines the set of real business terms will • Speed up implementation • Support standardization • Reduce costs for implementers and users • However, may restrict work processes • A common data vocabulary must be common to those who are stakeholders in the business scenario – i.e. international • The current pilots are resolved using different techniques and vocabularies – where is the standard?? • Skill demanding: ILS, PLCS, STEP, Express, IDEF0..