| | 134 | === A General Injunction Against the Requirement for Unique, Identified Literals === |
| | 135 | |
| | 136 | NRX is envisaging the case where a standards body provides definitions of various pieces of equipment using part 7. A supplier provides equipment specifications and references to maintenance routines, safety and handling documents and so on, perhaps referencing classifications from the standards body, certainly using tempaltes defined by the standards body, again all using part 7. An Engineering Procurement and Construction company might supplement that information with their own engineering details, also using part 7. A commissioning company might create equipment tags and add new data to that provided by the EPC, including for example, operating pressures and other control and monitoring data for the running equipment, also using part 7. The owner operator might add more data into their Asset Information Management (AIM) system , such as maintenance plan modifications, surrogate spares, use/criticality/reliability data and so on, also using part 7. They might plug that data into their Enterprise Resource Planning (ERP) system and integrate yet more data. We see ISO 15926 as the interoperability platform for all of this data. |
| | 137 | |
| | 138 | So the issue is that once this data reaches an AIM system, or an ERP system, it is in fact the merging of data from many different sources. Some of these sources are public (eg. standards bodies, vendors), some are private or privileged (eg. commissioning data). Some of these sources are enduring (eg. standards bodies) some are transient (eg. an EPC project). |
| | 139 | |
| | 140 | At the end of the day, the owner operator is collecting a large amount of data from many different sources and it is important to be able to identify the source of data, what is enduring, what is transient, what is public, what is private. It is also important that identifiers used in data do not collide. |
| | 141 | |
| | 142 | Now, consider the case that a supplier adjusts an equipment specification datum, or an EPC continues to make modifications to a design during commissioning. Data is again flowing. That new data must correlate and "patch" the existing data in an efficient, and fault-free manner. If we need to rename identifiers, then we have just introduced a substantial complexity to that act of patching the data efficiently and flawlessly. |
| | 143 | |
| | 144 | Not only must it "patch" the first system it encounters, it needs to patch every successive downstream system reliably and consistently. Not only that, but what about full circle actions? Isn't it possible that an ERP system might make direct contact with an OEM system using part 7 passed through this long chain? Isn't it possible that an aMDM system might consult the original standard reference against which an OEM categorized their equipment for more details or as the basis for a search for substitute equipment? |
| | 145 | |
| | 146 | So long story short, given that data is being continually merged from multiple sources, sometimes from the same source again and again, it is untenable for the identifiers to change or collide. Given that it is unreasonable to create a central registry of literals (for security, scalability and performance reasons), it is not far fetched to say that it is adviseable that literals are not identified at all, unless they absolutely must be for the relationships that they participate in. |
| | 147 | |
| | 148 | Note: that the authors of part 7 have declared the above use case to be "out of scope" as far as what part 7 is intended to address, however, there should be some "high degree" interoperability solution for ISO 15926 data, and I believe that the RDS/WIP should store information in that form, since it will be the focal reference system of these other "highly interoperable" ISO 15926 use cases. |
| | 149 | |
