| 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] |
