Changes between Version 11 and Version 12 of ISO15926Primer_HowItWorks_ComplianceColors

Show
Ignore:
Timestamp:
11/20/11 03:37:09 (10 years ago)
Author:
gordonrachar (IP: 75.156.216.35)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ISO15926Primer_HowItWorks_ComplianceColors

    v11 v12  
    33= How the ISO 15926 Compliance Colors Work = 
    44 
    5 ---- 
    6 [[PageOutline(2-4,Contents,inline)]] 
     5The '''ISO 15926 Primer''' has been replaced with '''An Introduction to ISO 15926''', a free download from Fiatech. 
    76 
    8 == Abstract == 
     7This page is out of date and has been deprecated. 
    98 
    10 An organization does not have to implement all of ISO 15926 at once.  It can, for instance, start with simply mapping some of its internal applications to Part 4, then work up in stages to developing a full ISO 15926-compliant façade.  The colors are shorthand descriptions of the level of compliance with ISO 15926. 
     9If you reached this page from a link in another web page please inform the webmaster. 
    1110 
    12 ---- 
     11For a peek at the new book and instructions on how to download a copy please follow this link. 
    1312 
    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] 
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