Changes between Version 48 and Version 49 of ISO15926Primer_Implementations_WhatBeenDone

Show
Ignore:
Timestamp:
11/20/11 03:41:39 (8 years ago)
Author:
gordonrachar (IP: 75.156.216.35)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ISO15926Primer_Implementations_WhatBeenDone

    v48 v49  
    44= What Has Been Done to Develop ISO 15926 = 
    55 
    6 ---- 
     6The '''ISO 15926 Primer''' has been replaced with '''An Introduction to ISO 15926''', a free download from Fiatech. 
    77 
    8 [[PageOutline(2-4,Contents,inline)]] 
     8This page is out of date and has been deprecated. 
    99 
    10 == Abstract == 
     10If you reached this page from a link in another web page please inform the webmaster. 
    1111 
    12 Organizations have been using the ISO 15926 dictionary, Part 4 (ISO 15926-4) for over a decade. 
     12For a peek at the new book and instructions on how to download a copy please follow this link. 
    1313 
    14 In the spring of 2009 two "proof of concept" projects were initiated.  They were successfully demonstrated at the May 2009 FIATECH conference in Las Vegas, Nevada. 
    15  
    16   * '''Proteus''' - Demonstrate the use of ISO 15926-4 to move plant data between 2D and 3D applications. 
    17  
    18   * '''Camelot''' - Implement the full specification of ISO 15926 including parts 7, 8, and 9. 
    19  
    20 ---- 
    21  
    22 == Origin of ''Proteus'' and ''Camelot'' == 
    23  
    24 In April 2008, FIATECH convened a meeting of Owner/Operators, EPCs, software vendors and equipment suppliers to see what could be done to demonstrate the usefulness of ISO 15926.  As a result, two projects were spawned: 
    25  
    26   * ''Proteus'', to demonstrate a realistic exchange of data between commercial 2D and 3D design systems using the ISO 15926 dictionary (ISO 15926-4). (Originally called ''Matrix'' ''123'') 
    27  
    28   * ''Camelot'', a proof of concept implementation of the full specification of ISO 15926, including part 7 (templates), part 8 (RDF & OWL), and part 9 (façade). (Originally called ''Matrix'' ''8'') 
    29  
    30 [[Image(Implement_01.JPG, 700px)]] 
    31  
    32 '''Fig 1 - ''Proteus'' and ''Camelot'' Information Exchange Subprojects''' 
    33  
    34 ---- 
    35  
    36 == ''Proteus'' == 
    37  
    38 A high priority identified in a wish list from end users was the ability to exchange plant data between different commercial plant design systems.  Users want to be able to exchange information between different P&ID applications, between P&ID systems and 3D systems, and between different 3D design systems.  Data flows carrying a realistic payload were demonstrated for each of these three situations. 
    39  
    40 == ''Proteus'' Data Flows == 
    41  
    42 The name, ''Proteus'', was chosen from its positive connotation in Greek mythology of flexibility, versatility and adaptability. 
    43  
    44 The Proteus project demonstrated three data flows that are typical in the project handover stage from EPC to Owner.  The scenario is a new plant project where there are a number of EPC's doing different parts of the work, each using different commercial plant design software.  The owner wishes to take delivery of the 2D and 3D engineering models and consolidate everything into its own chosen plant design system. 
    45  
    46 Five P&IDs and three 3D models were created and consolidated into a single system.  This project demonstrated the lowest level of ISO15926 compliance: Dictionary level – "Any XML file schema containing RDS/WIP class names". 
    47  
    48 === Fully Intelligent P&ID Handover of Data and Drawings === 
    49  
    50 [[Image(Implement_Proteus_01.JPG, 500px)]] 
    51  
    52   '''Fig 1 - P&ID to P&ID''' 
    53  
    54 The first data flow read the information from an AVEVA VPE P&ID, a !SmartPlant P&ID (using XMpLant as an intermediate step), a Zyqad PFD, and a Catia P&ID into an ISO 15926-compliant XML file.  The XML file was then read into a Zyqad PFD and a Catia P&ID. 
    55  
    56 === Integration of 2D Data With 3D === 
    57  
    58 [[Image(Implement_Proteus_02.JPG, 500px)]] 
    59  
    60   ''' Fig 2 - P&ID to 3D''' 
    61  
    62 The second data flow read the information from the same P&ID systems into the same kind of XML file as the first data flow, but this time read it into AVEVA's P&ID manager.  From there, the P&ID information was compared to a 3D model, showing that none of the intelligence was lost in the transfer between commercial systems. 
    63  
    64  
    65 === Intelligent 3D Models with Pipe Specs === 
    66  
    67 [[Image(Implement_Proteus_03.JPG, 500px)]] 
    68  
    69   ''' Fig 3 - 3D to 3D''' 
    70  
    71 The third data flow combined information from a PDMS 3D model, a PDS 3D model, and an AutoPLANT 3D model into two ISO 15926-compliant XML files.  One of the XML files was then read into the PDMS piping component catalogue, and the other XML file was read into the PDMS 3D design database, a Data Management system, and an Operations and Maintenance system. 
    72  
    73 === Scope === 
    74  
    75 In all cases, the payload was a realistic sample of data that would come from a modern Oil & Gas or Petrochemical plant handover. 
    76  
    77 Scope of Data Exchange: 
    78   * Tag No’s 
    79   * Schematic information (i.e., look and feel, topology) 
    80   * All P&ID connectivity, including off-page connectors 
    81   * Metadata of P&ID 
    82   * Use the ISO 15926 RDS/WIP for class names 
    83   * Use XMpLant schema 3.3 
    84  
    85 Not in Scope: 
    86   * Design data and process data 
    87   * Process data propagation rules 
    88     - flow direction 
    89     - spec-based restrictions 
    90     - metadata of represented objects 
    91  
    92 Some Issues: 
    93   * There are differing degrees of definitions in different systems, especially between 2D and 3D.  (e.g., a generic valve symbol in P&ID, but a more specific symbol in 3D.) 
    94   * Some rules may be lost due to the information that some systems do not retain: 
    95     - viability of certain valves in certain specs 
    96     - orientation of check valves 
    97  
    98 === Additional Benefits === 
    99  
    100   * Competing vendors have committed to deliver commercial interfaces for ISO 15926 Dictionary XML files for release by the end of 2009. 
    101  
    102   * Going forward, these same vendors have agreed to collaborate to test their interfaces. 
    103  
    104   * The ISO 15926 RDS/WIP has been extended to support ''Proteus''.  As organizations use Dictionary-enabled software, new opportunities will be identified to extend it further. 
    105  
    106 ---- 
    107  
    108 == ''Camelot'' - the Kitty Hawk of ISO 15926 == 
    109  
    110 Previously in the Primer we have used the metaphor of heavier-than-air flight.  Using this same metaphor, the ''Camelot'' demonstration in April 6, 2009 in Las Vegas was the ''Kitty Hawk'' of ISO 15926. 
    111  
    112   According to [http://en.wikipedia.org/wiki/Flyer_I Wikipedia], On December 17, 1903, on the sand dunes near Kitty Hawk, North Carolina, Orville and Wilbur Wright flew the first airplane on several short flights.  The ''Wright'' ''Flyer'', as it was called then, was crude by the standards that would become normal even few years later, but proved a number of concepts, not the least of which was [http://en.wikipedia.org/wiki/Wright_brothers three-axis control], a system developed by the bothers that solved the real problem of flight. 
    113  
    114   ''Man will fly, but not in our lifetimes.'' [[BR]] Wilbur Wright to Orville in 1901 after repeated failure during their second season of field trials. 
    115  
    116 ''Camelot'' was a proof of concept to show that realistic business information can be transferred between EPC, Owner/Operator, Instrument Vendor, and Constructor using ISO 15926 tools.  The software was made available under an open source license after the project was completed. 
    117  
    118  
    119 === Purpose of ''Camelot'' === 
    120  
    121 The purpose of ''Camelot'', was to demonstrate that the full ISO 15926 specification could be used to transfer information between several organizations in a realistic setting.  Thus, ''Camelot'' proved the viability of ISO 15926 by demonstrating several things: 
    122  
    123   * An ISO 15926 open source infrastructure on the Internet with the following capabilities: 
    124     * The use of ISO 15926 in modeling business information 
    125     * The setup, configuration, and use of publicly available tools to map legacy systems to ISO 15926 
    126     * The demonstration of several data exchange scenarios between several companies using ISO 15926 over the Internet. 
    127  
    128 It used the full ISO 15926 specification: 
    129  
    130   * Part 2 - Data Model 
    131   * Part 4 - Classes 
    132   * Part 7 - Templates 
    133   * Part 8 - RDF 
    134   * Part 9 - Façades 
    135  
    136 === ISO 15926 Realtime Interoperability Network Grid === 
    137  
    138 In every instance, the data item that was transferred started in a commercial or proprietary software application.  It was first transformed in its respective iRING adapter and transferred via the iRING web services to the target location where it was transformed again with an iRING adapter into the target application. 
    139  
    140 == ''Camelot'' Demonstration Data Flows == 
    141  
    142 === P&ID to P&ID - Property Update Scenario === 
    143  
    144 [[Image(Implement_Camelot_01.JPG, 500px)]] 
    145  
    146 '''Fig 4 - P&ID to P&ID ''' 
    147  
    148 The first data flow transferred P&ID line properties from a !PlantSpace P&ID to the same drawing in !SmartPlant P&ID. 
    149  
    150 The second data flow transferred P&ID equipment properties from an !OpenPlant PowerPID to the same drawing in !SmartPlant P&ID 
    151  
    152  
    153 === P&ID to Data Warehouse - Handover Scenario === 
    154  
    155 [[Image(Implement_Camelot_02.JPG, 500px)]] 
    156  
    157   ''' Fig 5 - P&ID to Data Warehouse ''' 
    158  
    159 The third and fourth data flows represented an EPC-to-Owner Operator scenario transferring P&ID data from two different P&ID products to a common data warehouse.  One data flow was from !PlantSpace P&ID and the other from !OpenPlant PowerPID.  Both were merged inside !SmartPlant Foundation. 
    160  
    161 This demonstration showed how ISO 15926 can transform information from one form (P&ID) into a completely different representation (data warehouse). Once the P&ID information data was in the data warehouse, Intergraph demonstrated how the relationship data of ISO 15926 could be exploited to open a 3D representation of the transferred data and use that representation to navigate through the information. 
    162  
    163  
    164 === P&ID to Data Warehouse - Visualization Scenario === 
    165  
    166 [[Image(Implement_Camelot_03.JPG, 500px)]] 
    167  
    168   ''' Fig 6 - P&ID to Data Warehouse ''' 
    169  
    170 The fifth and sixth data flows represented a project construction scenario where two EPCs communicate to one constructor.    
    171  
    172 In this demonstration pipe line properties, including pressure and temperature, in two different commercial P&ID applications were transferred to proprietary 3D construction visualization software at the constructor's office.  When the data was received by the constructor's 3D software, the new pressure and temperature values triggered rules that set the color of the pipe to show, in this example, high values for both attributes. 
    173  
    174 In the sixth data flow, job site delivery dates and hydrostatic testing statuses were sent from the constructors SQL Server database back to the data center of one of the EPCs.  
    175  
    176  
    177 === P&ID to Datasheet - Supplier Scenario === 
    178  
    179 [[Image(Implement_Camelot_04.JPG, 500px)]] 
    180  
    181   ''' Fig 7 - P&ID to Datasheet ''' 
    182  
    183 The seventh and eighth data flows were from different but related P&ID sheets at two EPCs to a supplier.  Vortex Flow Meter data sheet information from the P&IDs was updated into the supplier's data sheets running in Excel.   
    184  
    185 === P&ID to Datasheet -  Email Scenario === 
    186  
    187 [[Image(Implement_Camelot_05.JPG, 500px)]] 
    188  
    189   '''Fig 8 - P&ID to Datasheet via Email''' 
    190  
    191 Sometimes setting up web services to support data exchange directly between engineering applications might be difficult, or might violate an organization's Internet security policy.  The ninth and final data flow demonstrated the use of iRING technology without web service. 
    192  
    193 In this demonstration, the properties of some data values were published to an iRING adapter hosted in one office, and from there exported to an RDF file (A World Wide Web Consortium (W3C) standard) and emailed to the other office.  Once arrived, the RDF attachment was imported into the iRING adapter, then mapped and transformed and loaded into a SQL Server database. 
    194  
    195 '''References''' 
    196  
    197   * [http://iring.ids-adi.org/repository/org/ids-adi/camelot/End-of-Project/documents/Camelot-Project-Closeout-Report.pdf Camelot Closeout Report] 
    198  
    199 ---- 
    200  
    201 == Similarities and Differences between Proteus and Camelot == 
    202  
    203 The differences between Proteus and Camelot are in the payload capacity, the amount of preparation required before a data transfer (which is related to reuse), and the manner in which the data is transferred. 
    204  
    205 === Payload === 
    206  
    207 With Proteus we can transfer a realistic payload today.  In fact, the underlaying technology used in Proteus, XMpLant, has been used to transfer plant data between commercial 3D design systems in over 80 projects world wide, dating back to the mid 1990s. 
    208  
    209 With Camelot, the payload selected portions of realistic ''kinds'' of data that were transferred, but was not realistic in ''quantity''. 
    210  
    211 === Preparation & Reuse === 
    212  
    213 With Proteus, the preparation is mapping to the RDS/WIP, which is the ISO 15926 part 4 dictionary.  By its nature, dictionary-level mapping is something that must be done every time.  (In theory, once one 3D design system has been mapped, the mapping can be used on the next project.  But in reality, the software will likely change a bit by the time the next project rolls around, plus every EPC makes some tweaks to its database.) 
    214  
    215 With Camelot, the preparation is using the ISO 15926 part 7 templates.  The very first time, this is just as large a job as mapping to the part 4 dictionary.  However, over time mapping will have to be done less and less.  As more participants use part 7 and publish the templates, there will be less to do each time. 
    216  
    217 === Data Transfer === 
    218  
    219 With Proteus, the actual transfer of the information is not part of the technology.  Any method that gets the data files to the other end works, from FTP, to email, to sending a USB stick across the outback by pony express.  This technology is well suited to moving large quantities of information one time, or at discrete intervals, from one 2D/3D design system to another. 
    220  
    221 With Camelot, the transfer is a more-or-less continuous flow, in real time if you want it to be. 
    222  
    223 === Overall === 
    224  
    225   * Proteus is generally used to transfer a large chunk of information, with some significant planning ahead of time.  The technology underlaying Proteus is in use today. 
    226  
    227   * Camelot is intended to automatically connect two pieces of ISO 15926-compliant software, and to work in real time.  The technology underlaying Camelot is still in development. 
    228  
    229  
    230 [[Image(Implement_Proteus_Camelot.JPG, 300px)]] 
    231  
    232   '''Fig 9 - Difference Between Proteus and Camelot''' 
    233  
    234 Figure 9 shows how Proteus and Camelot approach the ultimate goal of digital interoperability from different directions. 
    235  
    236 Proteus, using XMpLant technology, is broad on the business axis and growing on the compliance axis.  Meanwhile Camelot, using iRING technology, is tall on the compliance axis and growing on the business axis. 
    237  
    238 With Proteus, each version of each 3D design system has to be mapped to ISO 15926-4 individually.  (You can think of this as making a decoder ring for a specific version of software.)  But as more software vendors get on board, and as EPCs and Owner/Operators with proprietary systems get on board, the number of decoder rings in existence grows.  Eventually, or so the proponents of Proteus say, we will be able to simply pull the appropriate decoder ring off the shelf (and perhaps tweak it just a little bit), instead of having to develop it from scratch.  Over time it will become easier to adapt an existing "decoder ring" to any particular project. 
    239  
    240 The Camelot approach, with underlaying iRING technology, is to make each piece of data smarter so that it knows what it is.  For instance, the value for "Maximum Allowable Working Pressure" will  appear to travel directly from the appropriate box in a data sheet in one system to the appropriate box in the data sheet in another system, all in real time if you want it to. 
    241  
    242 Going back to the metaphor of heavier than air flight, if Proteus is a heavy lift transport plane, Camelot is a swarm of personal jets.  Each solves a problem the other cannot. 
    243  
    244 ---- 
    245  
    246 == Avalon == 
    247  
    248 The Avalon project kicked off almost immediately after the Camelot project ended.  The iRING components had been successfully demonstrated on test data, but needed development for commercial use.  There were three purposes: 
    249  
    250 === Provide a Long Term Location for the RDS/WIP === 
    251  
    252 Currently the RDS/WIP is adequately hosted for experimental, and low-volume use.  But it can certainly not handle the kind of traffic of, say, a public search engine.  To move into world-wide production for all industrial users, a more robust home will have to be found. 
    253  
    254 POSC/Caesar and FIATECH, the original sponsors of the IDS-ADI project, have agreed in principle to manage this.  As of this writing, in the early winter of 2009, they are preparing joint business plans for this purpose. 
    255  
    256 === Provide A Means of Cataloguing the ISO 15926 iRING Source Code === 
    257  
    258 iRING is open source.  Potential users are encouraged to download the source code, use it at will, and participate in its further development.  The location is: 
    259  
    260   * http://code.google.com/p/iring-tools/ 
    261  
    262 === Provide a Central Forum For New ISO 15926 Implementers to Collaborate === 
    263  
    264 This goal was partially met in a [wiki:ISO15926HowTo_Introduction How To Guide] published on the POSC/Caesar site.   
    265  
    266 '''References''' 
    267  
    268   * [http://iring.ids-adi.org/repository/org/ids-adi/avalon/End-of-Project/ Avalon Closeout Report]  (Available January 2010) 
    269  
    270 ---- 
    271  
    272 == Next == 
    273  
    274   * [wiki:ISO15926Primer_Implementations_HappeningNow Primer: What is Being Done Now With ISO 15926?] 
    275  
    276 ---- 
     14  * [wiki:ISO15926Primer An Introduction to ISO 15926] 
Home
About PCA
Reference Data Services (RDS)
RDS Operations Support
Meetings and Conferences
ISO 15926
Special Interest Groups
Technical Advisory Board
Norwegian Continental Shelf Std
Projects
Search