|
|
 |
Repository Plant Data Warehouse and Data ModelREPOSITORY is a fully implemented plant data model that encompasses virtually all activities within a process plant. It has a proven database structure capable of managing the majority of plant information, thus REPOSITORY can act as a warehouse for plant data. REPOSITORY also acts as a database that can answer complex business questions by performing calculations and consolidating information from multiple systems, i.e. providing one stop shopping for all plant information. To do this it needs to be more than a plant data warehouse. Repository has an Object Registry as part of its' data model that maintains an index to all objects of interest in the facility. The Repository Meta-Model understands where data are stored about any object, and how to access that information when needed. Repository also contains a dynamic calculation engine that can use local and remote information to compute complex indicators.
What role the Repository database takes depends solely on the way the database is configured with data at each site. Note, no database table changes are needed to accomplish this. Every Resolution implementation at the same release level has identical data structures, views and stored procedures.
Resolution's plant data model is significantly more comprehensive, more complete, more adaptable, and more fully implemented than is any competitor's. A plant data model can be like a diagram of a complex process plant. There is a lot of work taking the plant data model from a diagram to a fully implemented system with other vendors, but not with Resolution because ALL of the implementation work has been done. Since Repository is implemented using industry-standard Oracle, any reporting tool that can access SQL immediately has access to all plant data. Special development tools are not required, or proprietary scripting languages, or custom query tools. There is no special-purpose API to the data within Repository other than SQL. It also runs on any server platform supported by Oracle. |
|
|||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
The REGISTRY stores a comprehensive catalog of all plant resources in the database. In the context of the database, a plant resource could be a piece of equipment, a project, a chemical, a document, etc... In fact a resource can be anything that needs to be managed. By putting all resources in a single place, it is much easier to build relationships between them. The Registry Object Catalog provides a common place for all entities involved in all of the different system and modules to be centrally catalogued. The catalog takes the form of a database containing the primary keys by which all of the different systems know the same, shared, entity. For Example, a pump referred to as 'Pump #5' in the maintenance system, may be known as 'Asset #27' in the financial system and 'G-101' in engineering, or a P&ID document known as 'PID 21-050-1120' to engineering would be known as 'P0501120.DGN' to the document management system. 
Another function of the Registry Object Catalog is to act as a router for messages that are used to communicate between systems. It maintains a subscription list identifying which system a message should be sent to when it receives a message from a particular system. The REPOSITORY meta-model is used to store additional data to support plant applications. REPOSITORY's flexible structure is easily configured for storing almost any data on plant resources. Specific structures are available for managing operations data and equipment specification information in a consistent manner, with full units of measure conversion. The following is a list of key information groups in the database. There is no segregation of data within the database, the groups are just used for ease of understanding the scope of Repository.
|
|
DATABOOK contains the expected performance of each operating unit. The information is stored in such a way as to enable comparison with plans or operating data. Databook also contains recipes with detailed steps, instructions and formulae.
DOCUMENT contains a document catalog with revision histories. It can track multiple copies of documents and can manage document sub-document relationships. FINANCIAL provides the link between the plant and cost accounting. Examples of such data are cost centers and commodity pricing information. FLOWSHEET contains a master list of flowsheet items and relevant plant connectivity information. It is a database description of the P&ID or PFD diagrams. Includes all plant locations, equipment and attachments. KPI contains plant key performance indicators and their relationships to other plant resources and calculations. MEASURE maintains configuration data for measuring devices. Specific items tracked are Labs, Sample Points, Tests, Lab Procedures and Instruments. MOVEMENT tracks planned and actual receipts, shipments and internal plant movements of materials by commodity. Battery limits and lineups can be defined. NOMINATIONS tracks shipping receipts and transfers, jetty use, ships, voyages, carriers and cargoes. PLANS contains details of the plans that have been developed to set the strategy of operations. e.g. Monthly LP Plans, Daily schedules etc. It manages inventory at plant locations, including batch and lot tracking information. PROPERTY controls the master lists of properties, units of measure and their conversion equations. PVDATA contains process tag configuration information. Tags can be internal to Resolution or in external systems. REFERENCE contains design and specification data for any resource. Generic specification information and suggested values can be defined by type of resource. RESOURCE contains the "Master Catalog" of all resources along with their synonyms in different systems. SECURITY maintains a list of all valid users of the database and their privileges to execute specific operations on database and non-database objects. TIMEINT contains information required to support daylight savings time adjustments and time-zone corrections. |
|
|
|
Repository can act as the plant 'operational data store', where unlike a data-warehouse, information can be created, read, updated and deleted. Applications can use the Repository database as their native data store, and the Resolver user interface is available for data entry, update and retrieval. Repository can fill in the gaps between best of breed applications because even after integration of all the applications it will be found that there is still some information that is not managed in any database. Many legacy systems are not good custodians of their own data. Many have limited capability to store historical data in an accessible format and many only provide access to their data through their own application system. Repository can be the data warehouse that makes the historical data consistent and accessible. Data Warehouses often store aggregated data. Resolution stores the fundamental data and aggregates it on demand using optimized fact views. Repository delivers the same 'hyper-cube' views of data but without the need to replicate the data into a separate database. It does this via 'fact-views', that appear the same as a true data warehouse to an OLAP tool. However, they have the advantage that new fact-views can be created with little effort, the fact-views can have dimensions without any limit of granularity, and the facts are always based on the most up-to-date information. 
Repository does not have to retain a copy of the data. Instead, it acts as a meta-model by which we mean it uses its knowledge of the plant to fetch the information from the legacy systems when it is required in a calculation, report or to be viewed by a user. If Repository does not have the data values, it uses Relayer to fetch them from an external system. If a database query (using any query tool) does not find the data locally within Repository, it will send out a message via Relayer messaging. The results will be then returned seamlessly as part of the query result set. Note: one result set may contain data from multiple external databases. Repository uses this technique to communicate with real-time databases such as OSI PI or Honeywell PHD. Because the time overhead is so low, it means real-time does not need to be stored within the Repository database. It can always be retrieved on demand. In an ideal world Repository would only contain references to external data, and would not need to function as an operational data store or as a data warehouse. However, in practice, many systems are not good custodians of their own data: they are not designed for long term data storage, they only contain current data, the interface is not designed for ad-hoc query, and many other reasons. For this reason a lot of the information needs to be stored in Repository. Since we cannot be sure what data has a good home, the Repository data model has been created to accommodate all plant data. Repository includes the Reevaluator calculation engine that can execute complex calculations on-demand. It means requested values can be the result of calculations so they do not have to be stored at all. Reevaluator is a very powerful facility, it can execute calculations of virtually unlimited complexity. |
  |
||
 |
Copyright 2003, Resolution Integration Solutions, Inc. Web Design & Development by  |
|
Benefits
