| 14 | | == Introduction to ISO 15926 Compliance == |
| 15 | | |
| 16 | | The scope of ISO 15926 is nothing short of integration of all the information about any process plant from conception, through engineering, construction and commissioning, all the way to decommissioning and dismantling many years later. With such a large scope, there are many intermediate steps to implementing the full ISO 15926 specification, each step giving an incremental business value. Therefore, the concept of Compliance Colors was introduced to give implementers of ISO 15926 a roadmap. |
| 17 | | |
| 18 | | Figure 1 shows the broad bands of compliance: |
| 19 | | |
| 20 | | [[Image(ComplianceColors_RoadMap.JPG, 400px)]] |
| 21 | | |
| 22 | | '''Figure 1 - ISO 15926 Compliance Colors''' |
| 23 | | |
| 24 | | Ambiguity is the enemy of digital interoperability. For an example, consider the lowest entry on the chart, a Comma Delimited File. Typically, an application writes out a text file containing the database name, table names, and column names as a header, then the data values of each column separated by commas (hence, the name). This kind of file is often the lowest common denominator for transferring information between applications. It's simple to make and, with just a bit of training, easy for humans to read too. |
| 25 | | |
| 26 | | But, obviously, one cannot transfer information between two applications by simply mapping together a random database column in each and expect anything worthwhile. A human expert will have to first determine which columns in each application are equivalent, then set up the export and import between the equivalent columns--in short, remove the ambiguity by studying what the two applications do. |
| 27 | | |
| 28 | | But the vision of digital interoperability is that machines talk directly to machines without human intervention. The ISO 15926 specification includes a number of techniques one can use, stepping stone fashion, to remove the ambiguity in stages until arriving at full compliance. At each step more ambiguity is removed so information exchanges require less human intervention. |
| 29 | | |
| 30 | | == Many Axes of Compliance == |
| 31 | | |
| 32 | | In practice ''compliance'' is a checklist of how all relevant aspects are addressed in your implementation. Combinations of these aspects have been grouped all the way from none through Yellow, Green, Blue to Red, full compliance. The check list is still relevant, but the color coded bands make it easier to target meaningful levels of compliance that support particular business benefits in ways that will support progress to greater benefits as experience is gained. |
| 33 | | |
| 34 | | Bear in mind that compliance is defined at interfaces (thus, the slogan "15926 Outside (R)".) ISO 15926 says nothing about how your applications and databases are structured internally in your business, although we are all encouraged to use the same compliance approach internally as well. |
| 35 | | |
| 36 | | The compliance checklist covers several aspects: |
| 37 | | |
| 38 | | * The level of ambiguity in the templates and reference data content. This ranges from simple "dictionary level" naming to fully Part 2-explicit-Part 7 references for all content. |
| 39 | | * The level of standardization. Whether the reference content used is standardized within one enterprise, within industry communities, or with standards bodies such as ISO. |
| 40 | | * The physical form used to represent content at interfaces. This ranges from file exchanges to web-service API's, and from XML schema to RDF-OWL representations. |
| 41 | | * The scope of content management supported, both "payload" and "management metadata" capabilities. |
| 42 | | |
| 43 | | [[Image(ComplianceColors_Categories.JPG, 650px)]] |
| 44 | | |
| 45 | | '''Figure 2 - Valid Compliance Category Combinations''' |
| 46 | | |
| 47 | | === Compliance Level Overview === |
| 48 | | |
| 49 | | There are four broad bands of compliance: |
| 50 | | |
| 51 | | '''Yellow - Dictionary Compliance''' |
| 52 | | * The minimum level of compliance using any schema with RDL terminology |
| 53 | | * Can use embedded RDL Designators or Endpoint URI references |
| 54 | | |
| 55 | | '''Green - Public Template Compliance''' |
| 56 | | * Uses implementations of Public Templates according to the Part 7 Characterization Methodology |
| 57 | | * “Public” templates do not necessarily map unambiguously to “Private” (Part 2-explicit-Part 7) Templates |
| 58 | | |
| 59 | | '''Blue - Part 7 Template Compliance''' |
| 60 | | * Full Part 7 templates unambiguously represent "Private" (Part 2-explicit-Part 7) Templates |
| 61 | | * Are not implemented using Parts 8 & 9, OWL/RDF & Façades |
| 62 | | |
| 63 | | '''Red - Full Compliance''' |
| 64 | | * WIP endpoint URIs certified by and ISO 15926 Part 4 authority |
| 65 | | * Full Part 7 Templates |
| 66 | | * Part 8 RDF/OWL schema |
| 67 | | * Part 9 Façades |
| 68 | | |
| 69 | | |
| 70 | | |
| 71 | | At this level any interface supporting these representations and web services will automatically interpret exactly the same unambiguous semantic content. |
| 72 | | |
| 73 | | All levels are intended to be compatible with lower levels. That is, Red level can read any Blue, Green, and Yellow; Blue level can read any Green and Yellow; and Green can read any Yellow. |
| 74 | | |
| 75 | | ---- |
| 76 | | |
| 77 | | == Stewardship Capability Axis == |
| 78 | | |
| 79 | | Most exchanges of data between interoperable applications happen as part of ongoing business activities which involve management obligations and contractual responsibilities between parties. It is therefore necessary that stewardship metadata be ''managed'' ''responsibly'' by the systems representing compliant interfaces. |
| 80 | | |
| 81 | | [[Image(ComplianceColors_StewardshipCapability.JPG, 650px)]] |
| 82 | | |
| 83 | | '''Figure 3 - Range of Stewardship Capability Axis''' |
| 84 | | |
| 85 | | '''Export''' |
| 86 | | |
| 87 | | The ability of a system to deliver compliant content from one interoperable application to another, independent of the data scope or interface technology. |
| 88 | | |
| 89 | | '''Import''' |
| 90 | | |
| 91 | | The ability of a system to receive compliant content from another interoperable application, independent of the data scope or interface technology. |
| 92 | | |
| 93 | | '''Seed''' |
| 94 | | |
| 95 | | The ability of a system to persist imported data, independent of any existing data, and even if there is no existing data. |
| 96 | | |
| 97 | | '''Consolidate''' |
| 98 | | |
| 99 | | The ability of a system to consolidate and/or maintain relationships between added, deleted, or modified data and relationships on the basis of system ''internal'' keys and metadata. |
| 100 | | |
| 101 | | '''Reconcile''' |
| 102 | | |
| 103 | | In addition to ''consolidate'' (above), the ability to correlate and maintain ''external'' keys and metadata. |
| 104 | | |
| 105 | | ---- |
| 106 | | |
| 107 | | == Stewardship Metadata Scope Axis == |
| 108 | | |
| 109 | | In ISO 15926 terms, business process management metadata (ownership, versioning, status, etc.) is just more data. In terms of the scope of data involved in any compliance claim, it is important that not just the business-payload scope be recognized, but the scope of the stewardship business-metadata too. |
| 110 | | |
| 111 | | [[Image(ComplianceColors_StewardshipMetaDataScope.JPG, 650px)]] |
| 112 | | |
| 113 | | '''Figure 4 - Range of Stewardship Metadata Scope Axis''' |
| 114 | | |
| 115 | | '''Identity''' |
| 116 | | |
| 117 | | Metadata representing keys to object identity only. (''whole'' ''life'' ''individuals'') |
| 118 | | |
| 119 | | '''Version''' |
| 120 | | |
| 121 | | Metadata representing keys to object identity including version identity for versionable objects. (''temporal'' ''part'' ''objects'') |
| 122 | | |
| 123 | | '''Status''' |
| 124 | | |
| 125 | | Metadata representing the keys to object identity and version plus metadata representing system-independent business process status of objects. |
| 126 | | |
| 127 | | ---- |
| 128 | | |
| 129 | | == Payload Scope Axis == |
| 130 | | |
| 131 | | This axis is ultimately a matter of the evolving scope of reference data. By its nature, the WIP will be constantly growing. The BIDG, currently under development, will contain recommendations for the scope of information handovers for capital projects. The intent is not to make the Compliance Categories dependent on the ''which'' ''data'' payload scope, however it is necessary to highlight how compliance is affected in practice by these scope issues. |
| 132 | | |
| 133 | | |
| 134 | | [[Image(ComplianceColors_PayloadScope.JPG, 650px)]] |
| 135 | | |
| 136 | | '''Figure 5 - Range of Payload Scope Axis''' |
| 137 | | |
| 138 | | '''Business Interfaces Definition Guide (BIDG)''' |
| 139 | | |
| 140 | | The value of any ISO 15926 implementation is limited by the scope of sharable reference data in the WIP. Standardized scopes of data--both business-payload and business-metadata--relevant to different application needs are defined in the BIDG. Ultimately such definitions will be maintained by SIGs and persisted in WIP reference data. |
| 141 | | |
| 142 | | For more information about the BIDG, see ''Reference'' ''Information'' below. |
| 143 | | |
| 144 | | '''Geometry''' |
| 145 | | |
| 146 | | Where compliance scope concerns primarily 2D and 3D geometric shape data, a compliance category is proposed based on existing de facto industry methods for mapping and exchanging such data based in ISO 10303 (STEP) Part 42 shape representation, and on XML reference to objects identified and presented at least in terms of the WIP Classes as simple attributes. |
| 147 | | |
| 148 | | '''Application''' |
| 149 | | |
| 150 | | Some business interoperability scopes are best defined in terms of common software application types (e.g., Intelligent P&IDs.) |
| 151 | | |
| 152 | | '''Customer Content''' |
| 153 | | |
| 154 | | Compliant product shall be capable of exposing ''all'' customer content data according to the compliance category applicable. |
| 155 | | |
| 156 | | ---- |
| 157 | | |
| 158 | | == Semantic Precision Axis == |
| 159 | | |
| 160 | | The Semantic Precision Axis is a matter of how the business information ''as'' ''understood'' by the business relates to the information modeled ''as'' ''intended'' by ISO 15926. This is therefore the most technically significant in terms of the Compliance Categories. |
| 161 | | |
| 162 | | [[Image(ComplianceColors_SemanticPrecision.JPG, 650px)]] |
| 163 | | |
| 164 | | '''Figure 6 - Range of Semantic Precision Axis''' |
| 165 | | |
| 166 | | '''Dictionary Level''' |
| 167 | | |
| 168 | | ''Dictionary Level'' means that the only part of ISO 15926 you use is the RDL (that is, ISO 15926 Part 4) to make sure your entity names match the RDS/WIP class names. Mapping from internal applications and databases relies only on the naming and human text definition of those objects, regardless of how sophisticated your data model is at your interface. |
| 169 | | |
| 170 | | There are two ways to do this: |
| 171 | | |
| 172 | | * The most direct way is to hard-code the class names into an application or exchange file. The disadvantage is that the status, definitions, relationships and inheritances of those named RDL resources may not be in sync with the current WIP shared by the industry. |
| 173 | | |
| 174 | | * A better way is to use the WIP Endpoint URIs rather than the class names. This keeps the entity types in sync with the current WIP. |
| 175 | | |
| 176 | | Since Templates are not used at this level, the use of common types can still be ambiguous in terms of validating entity typing and the semantics of properties and relationships. The greater the ambiguity, the greater the business risk and the greater the cost of mapping, validation and re-processing data. |
| 177 | | |
| 178 | | '''Public Templates''' |
| 179 | | |
| 180 | | The next level of semantic precision is to use what we call ''Templates''. Mapping terms together using a common dictionary makes sure the correct information is conveyed, but you will always need a human expert at each end of the transaction to make sure the terms are used in the correct manner--that is, to preserve the semantics. Using Templates more-or-less embeds the semantics into the information transfer. |
| 181 | | |
| 182 | | The first level of using Templates is what is called ''Public Templates''. This means that your organization would use the same RDL items but build in its own relations and semantics to make its own proprietary templates. These templates are "public" in the sense that their naming, content, and usage is intended to be intelligible to human business domain experts. |
| 183 | | |
| 184 | | Within your organization these templates would remove ambiguity (and consequential risk and cost) in information transfers. |
| 185 | | |
| 186 | | Public Templates are valid ISO 15926 implementations and will satisfy immediate business needs, but will likely require further re-mappings to achieve full and unambiguous business lifecycle needs ''as'' ''intended'' by ISO 15926. |
| 187 | | |
| 188 | | |
| 189 | | * These ''Public'' ''Templates'' have previously been referred to as: |
| 190 | | * shortcut Templates |
| 191 | | * Part-7-Lite |
| 192 | | * P7L |
| 193 | | * Gellish |
| 194 | | |
| 195 | | The Characterization Methodology (or ISO 15926 Part 11 ''draft'') contains additional details of simplified methods for characterizing industrial data using Public Templates. |
| 196 | | |
| 197 | | '''Full Part 7 Templates''' |
| 198 | | |
| 199 | | ''Part 7 Template Level'' removes all semantic ambiguity by expressing all content in terms of Part 2-explicit-Part 7 templates. These templates are "private" in the sense that no business domain expert is expected to interpret their content and usage. Thus, there may be many "public" templates that exist for the same purpose and that are, conceptually, equivalent, but only "private" templates" guarantee that the semantics will be preserved. |
| 200 | | |
| 201 | | (It is important to recognize that stepping from the Public to the Full Part 2-explicit-Part 7 Template levels of semantic precision involves additional business-and-modeling-knowledgeable mapping effort.) |
| 202 | | |
| 203 | | * These ''Full'' ''Part'' ''7'' ''Templates'' have previously been referred to as: |
| 204 | | * Private Templates |
| 205 | | |
| 206 | | |
| 207 | | The only remaining ambiguity at this level is in how these templates are physically presented at your interface in terms of formats, schemas and services. See "Implementation Schema Axis", below. |
| 208 | | |
| 209 | | ---- |
| 210 | | |
| 211 | | == Standardization Level Axis == |
| 212 | | |
| 213 | | This axis recognizes that WIP reference data may be shared through any number of RDL’s federated over the web, enabled using the Part8/Part9 "iRING" technology architecture. |
| 214 | | |
| 215 | | [[Image(ComplianceColors_StandardizationLevel.JPG, 650px)]] |
| 216 | | |
| 217 | | '''Figure 8 - Range of Standardization Level Axis''' |
| 218 | | |
| 219 | | These libraries may range from: |
| 220 | | * Relatively informal “sandboxes” used privately within organizations or shared by agreement between business partners |
| 221 | | * Global sandboxes shared by a wider industry community. |
| 222 | | * Libraries certified by standardization bodies, including, eventually, ISO or W3C. |
| 223 | | |
| 224 | | This federated approach recognizes two factors: |
| 225 | | |
| 226 | | * This architecture enables rapid creation and use of proposed new RDL items, independent of any certification process time scales subject only to agreement of those business partners – but preserves the same endpoint URI’s so that programmatic dependencies on such content are preserved if and when certification processes are subsequently followed. |
| 227 | | |
| 228 | | * There are basic competitive reasons why multiple industry communities and standardization bodies should be able to share the same resources, and that not all those RDL resources need necessarily be constrained by 15926 Part 4 compliance. |
| 229 | | |
| 230 | | The Standardization Levels are: |
| 231 | | |
| 232 | | 1. Private Sandbox RDL |
| 233 | | 1. Community Sandbox RDL |
| 234 | | 1. Global Sandbox RDL |
| 235 | | 1. Certifying Authority RDL |
| 236 | | 1. Standardization Body RDL |
| 237 | | |
| 238 | | ---- |
| 239 | | |
| 240 | | == Implementation Schema Axis == |
| 241 | | |
| 242 | | The Implementation Schema Axis measures the choice of schema used to represent the semantic information. |
| 243 | | |
| 244 | | [[Image(ComplianceColors_ImplementationSchema.JPG, 650px)]] |
| 245 | | |
| 246 | | '''Figure 9 - Range of Implementation Schema Axis''' |
| 247 | | |
| 248 | | '''Implicit/non-XML Schema''' |
| 249 | | |
| 250 | | A schema implicit only through the constrained structure of non-XML exchange files and methodologies. (For example, the proposed Gellish Spreadsheet mapping methodology and format.) |
| 251 | | |
| 252 | | '''Any Explicit XML Schema ''' |
| 253 | | |
| 254 | | The use of any XML Schema or other Document Type Definition implemented in XML. This includes the explicit XML Schema form of Public Templates and other proprietary or standard public schemas. |
| 255 | | |
| 256 | | '''Any ISO 15926 Schema''' |
| 257 | | |
| 258 | | The use of any schema that uses ISO 15927 terms from the RDS/WIP. This includes implementations that use Public Templates and full Part & Templates. |
| 259 | | |
| 260 | | '''Full RDF/OWL Schema''' |
| 261 | | |
| 262 | | This is an explicit schema implemented using the RDF/OWL XML as defined in Part 8. |
| 263 | | |
| 264 | | ---- |
| 265 | | |
| 266 | | == Implementation Interface Axis == |
| 267 | | |
| 268 | | This Implementation Interface Axis shows the technology choice for interface. |
| 269 | | |
| 270 | | [[Image(ComplianceColors_ImplementationInterface.JPG, 650px)]] |
| 271 | | |
| 272 | | '''Figure 10 - Range of Implementation Interface Axis''' |
| 273 | | |
| 274 | | '''File Exchange''' |
| 275 | | |
| 276 | | Interface using an intermediate file that is compatible with the schemas on each side of the transfer. |
| 277 | | |
| 278 | | '''API or Query''' |
| 279 | | |
| 280 | | Interface using the API or query language of the applications on either side of the transfer. |
| 281 | | |
| 282 | | '''Part 9 Façade''' |
| 283 | | |
| 284 | | Interface using the Part 9 Façade, which would include a Web interface with SPARQL queries. |
| 285 | | |
| 286 | | ---- |
| 287 | | == Reference Material == |
| 288 | | |
| 289 | | '''Compliance Specification''' |
| 290 | | |
| 291 | | This page is a (somewhat) condensed version of the "ISO-15926 Compliance Guideline" v1.2, written by Ian Glendinning of DNV. If you are seriously considering implementing ISO 15926 in your organization, this document is required reading. For a discussion about compliance and a link to the document itself, follow this link: |
| 292 | | |
| 293 | | * [https://www.posccaesar.org/wiki/IdsAdiComplianceSpecification Compliance Specification] |
| 294 | | |
| 295 | | '''Business Interfaces Definition Guide (BIDG)''' |
| 296 | | |
| 297 | | The ''Business'' ''Interfaces'' ''Definition'' ''Guide'' is jointly written by FIATECH and NIST. It addresses the kind of information that should be handed over to the owner by the EPC at the completion of a capital project. |
| 298 | | |
| 299 | | * [https://www.posccaesar.org/wiki/ISO15926Primer_OtherResources#BusinessInterfacesDefinitionGuideBIDG Business Interfaces Definition Guide] |
| 300 | | |
| 301 | | == Next == |
| 302 | | |
| 303 | | * [wiki:ISO15926Primer_HowItWorks_TechnicalDetails Primer: Technical Information About ISO 15926] |
| 304 | | |
| 305 | | === Acknowledgements === |
| 306 | | |
| 307 | | Thanks to Ian Glendinning, of DNV, for the Compliance document this pages is based on. |
| 308 | | |
| 309 | | ---- |
| | 13 | * [wiki:ISO15926Primer An Introduction to ISO 15926] |
