|
|
 |
RIS Frequently Asked Questions2. RESOLUTION INTEGRATION ARCHITECTURE 2.1 How Does Resolution Integrate, Interface, Cooperate, And Unify? 2.2 What Is The Role Of Relayer? 2.3 What Is The Role Of Repository? 2.4 What Is The Role Of Resolver? 2.5 Is Resolution Ready for the New Environments? 2.7 How Does RESOLUTION Store All Of The ‘Other’ Data That A RTDB Cannot? 3. RESOLUTION INFORMATION MANAGEMENT 3.1 How Can Resolution Help Standardize Complex Relational Database Designs? 3.3 How Does Resolution Help Manage The Accuracy Of Stored Information? 3.4 Can Resolution be Extended to Handle Different Data? 4.1 How Can A Client Develop Additional User Interface Screens? 4.2 How Can Users Want To Write Their Own Reports? 4.3 How Can I Access The RTDB Data Via Resolution? 4.4 Do I Have to Use Resolution Tools to Access The Data Via MSOffice? 5. RESOLUTION APPLICATION STRATEGY 5.1 Does Resolution Provide Integrated Applications? 5.3 How Does Resolution Ease Maintenance? 5.4 How Does Resolution Ease Current And Future Application Choices? 5.5 How Easy Is It To Add Interfaces To Other Application Systems? 6. RESOLUTION IMPLEMENTATION STRATEGY 7. RESOLUTION’S CLIENTS’ EXPERIENCES
Instead of defining what 'Systems Integration' means, let’s discuss the problems (business and technical) that require integration for a solution. Business units within an enterprise have, traditionally, been very self-contained. This phenomenon is not confined to the refining or process industry. Look at government (or better yet, don’t look there for an example to follow!). They are a classic example of one hand not knowing what the other is doing. In Britain you can get a Government grant for reclaiming wetlands from the Department of Agriculture, and another grant for NOT reclaiming wetlands from the Department of the Environment! Initially cooperation develops between departments out of sheer necessity. It usually takes the form of the interchange of COPIES of information (memos, declarations, reports, lists, etc in hard-copy or electronic format). Thus each business unit develops a vast filing system, 80% of which is data that has been copied from outside. Since it has been copied, the quality of the data contained therein deteriorates rapidly. Applications model themselves after the business unit that they support. So guess what: they also copy the data from the applications with which they must interface. Not only is this a natural consequence of modeling the application after the behavior of the business unit, but it is codified in our development procedures: the first diagram of a functional specification is the context diagram showing how the data is going to be cloned from these other systems. Thus businesses have made the first step in creating, not islands of automation, but icebergs of information: each business unit/application has, on the surface some information (hardcopy/electronic) that it clearly owns, but has much more beneath the surface copied/stolen/borrowed from other business units/applications. Herein lie the problem and the need for integration and cooperation. There is another consequence of the evolution of isolated business units: they all start talking different languages! The same word can have a different meaning, or the meaning can be conveyed by different words or codes. A simple copy or reference to the information requires that it be accompanied by its complete meaning. For example SRN could either be State Registered Nurse or Straight Run Naphtha. There is a difference. If you do not think this is important, then look at the Mars Explorer: information (thrust) was copied (by fax) without the complete meaning (units-of-measure). The consequence is that there is no longer a Mars Explorer! Finally where is the information? Given that most organizations create multiple copies of information, we need to know who is the real originator. How this manifests itself depends on the type of organization. In some, notably Government, you will be sent from one department, to another, to another, etc. Each one will deny knowledge. Ask some plants for information about instruments and you will be offered 5~20 different sources which should be checked. Thus: Integration is the means by which information, the meaning of information, and the location of the information can be reliably shared. It is a myth that there are competing ways of creating an integrated architecture: CORBA/COM/DCOM/Messaging/Relational database/Object database/XML/Internet/SOAP. If we clear away all of the noise, we can see that any business process consists of tasks or functions that need to happen. These tasks might be entirely manual such as sign for shipment release, or fully automated, such as reconcile the observed measurements. These tasks, to be of any use, are going to produce results (information) that have value if it is communicated (information flow). Conversely an outside use might not have his own copy of the information so will want to know where to get it (information location). Information: If the application systems themselves are not going to be good custodians of their own information, then a part of the integration solution is going to have to shoulder that responsibility. At present this will be a relational database, but even these are adopting more and more object-orientated features. In the future we will see complementary technologies such as XML servers. Information flow: Information has value when it flows. Information stuck in an impenetrable location (I will not say warehouse) has no value whatsoever. We have to get the information in or out of the application (interface): not many realistic choices here except COM, DCOM and CORBA, replacing RPC and vendor supplied interface APIs. Then we are going to communicate it to another application (integrate): this is much newer but XML-based message transports such as SOAP that work over the internet as well as local networks look very promising. Information location: to find information either in a single application or across multiple applications you need a map. That is what a relational model is: an organization model of the data. I follow CODD in my belief that the relational model (not to be confused with SQL) is the 'lingua franca' of data modeling. ALL data structures can be expressed in a relational model, whilst alternatives must be regarded as subsets. Yes, the alternatives might have implementations that are more succinct than SQL, but they are not as expressive. An analogy is other development tools: Visual Basic is very powerful, but it will never do as much as C++. It is generally assumed that a database must map and own the data, but why? There are technologies that allow a relational database to both own and access the data, using its own internal model to manage this process. Firstly, it is unrealistic of a site to be considering customization of an application system: It is neither the core business nor core competency of most refiners. It has been shown over and over that internally developed or heavily customized applications have a high mortality. There are obvious reasons: Development effort is only a fraction (~10%) or commercialization effort. During the lifetime of an application, users will require that its functionality will double. Are sites prepared to make this commitment? It is therefore the obligation of the COTS solutions to provide an interface, thus eliminating the need for solution customization. But the applications are only the building blocks of an integrated solution: Having a stack of bricks is not the same as owning a house! The cement is managing the intra-application information, information location, and information-flow. Can this be done with COTS? Yes to some extent, but this is a rapidly emerging area. I believe we shall see more in this area, giving refiners even less reason to be developing their own application information databases, information location models, and information-flow managers. COM/CORBA: Until recently every application system had an entirely different application-programming interface. It could be via C-library calls, flat-files in and out, ODBC, remote-procedure-calls. Each interface was crafted from whatever was available. Integrating two applications involved some, expensive, mysterious, programming that no one else understood, leaving the organization trapped in a particular architecture that was very expensive to maintain. COM/CORBA at least defines a uniform way for two programs to talk to each other. They still have to understand what each other are saying, which is not a trivial problem but at least it solves part of the problem. Object Orientated Request Brokers/Messaging/XML: How do you move information between systems? All sorts of methods have had to be used: FTP, shared files in a specified directory, capturing the printer output and many other creative means. These often were expensive or difficult to maintain because security, communications failure, failure recovery, translation, routing etc at should have been built into each interface but were often omitted. These technologies allow some element of standardization. Integration is the means by which information, the meaning of information, and the location of the information can be reliably shared. Resolution is specifically designed to be the 'back bone' that integrates, unifies, and interfaces applications. Resolution is not just middle-ware, although Relayer performs this role; it is not just a database, although Repository provides operational data store, data-warehouse, and meta-model functionality; and it is not just a user interface, although Resolver provides a comprehensive library of user interface applications. Relayer messaging makes data required for and the information generated by applications available to other applications in a timely, consistent, standard, easily managed, guaranteed delivery, system. Relayer provides the site with true plug-and-play integration of applications. Any application attached via Relayer to the Resolution system does not need to know the specifics of any other applications. Relayer handles all of the messaging routing and translation. Thus, if a laboratory system becomes obsolete, another system can be put in its place and as long as the new system produces the same generic laboratory messages, and can respond to the same incoming messages, all other systems are totally unaware that the change has occurred and as such do not have to be reprogrammed. Repository is the database that can provide business questions with one stop shopping for any and all plant information. It does not do this by simply acting as a data warehouse. Resolution Repository acts as an operational data store, data warehouse, and a meta-data model (in which the database only keeps the location not the data) simultaneously. What role the Repository database takes depends solely on the way the database is configured with data at each site. Note that this never requires redefining the table structure or procedures to support the table. Each implementation has identical data structures. Since Repository is implemented as a pure SQL database, any reporting tool that can access SQL immediately has access to all plant data. There is no special-purpose API to the data within Repository other than SQL. Resolver is a library of user interface applets that allow the user to interact (select, insert, update, and delete) with the data in the database or other systems. As well as being fully functional applications these applets can be used as building blocks in more complex, site-specific applications. RIS has always been at the forefront of technology. RIS’s focus on technology development ensures that it will retain this lead. User Interface and Intranet: Resolver applets provide a full user interface to the database (and thus to any data within and attached system). These can be used 'as-is' or, since they are ActiveX/OCX components as well, be used as components within another application. Since they are ActiveX/OCX components they can and do form part of Active Web documents. Resolution is implemented as an n-tier architecture as follows: Database layer: Passive SQL: In this layer of the system reside the table definitions together with the referential integrity constraints and indices. The former are used to ensure that the data never becomes inconsistent either via a read, update, insert, or delete operations. Also included at this level are database triggers used to control the automatic auditing, audit history, and record-level access control that is unique to Resolution. Although interfacing is possible at this level and the database will protect itself, direct table access is not encouraged. Active SQL: Resolution makes much greater use of the capabilities of the database than the majority of systems. In the active SQL layer, Repository has a large number of database-stored procedures and views that effectively 'de-normalize' the underlying table structure. Note though that the database preserves its actual normalized structure. The stored procedures are used to populate the underlying tables, avoiding the need for an application programmer to perform this within either the application server or client application code. The views are used to reconstruct the information from multiple tables into a single pseudo-table. This is the lowest level at which we recommend users interact with the database. Any Oracle SQL compliant interface can access the database at this level. Application Server Layer: Reader: Reader provides a single interface to the database. Although built upon ADO, it has the advantage that a single database connection can be shared by many applications on the same client simultaneously, even when those client applications keep, say, database cursors open continuously. Reader presents a COM/DCOM interface to an application. Resolver Foundation Classes: This is a library (DCOM/COM/DLL) that presents an application programmer with a suite of COM classes. Each class represents a database table. The class can retrieve data from the database automatically, and, when changes are made to the contents of the class update, issue the correct database update, delete, or insert statements. Each class may be related to another class. For example records can be fetch into one Foundation Class on condition that some of the fields match the values of another foundation class. These classes provide a most productive foundation for developing additional applications. Client layer Toolkit OCX: The Toolkit OCX's are a presentation toolkit from which more comprehensive applications can be constructed. This OCX toolkit includes master/details, grids, hierarchies, GANTT charts, etc. The toolkit also provides other services such as desktop management, logon, Resolving etc. Note that that little or no data manipulation is performed at this or higher levels. Applet OCX: Applet OCXs are fully functional applications, but focusing on a single application area. Therefore KPI-DependentKPI management is performed by an applet. These applets can either be used standalone or combined into a more complex application. Applications: The OCX's need an environment or process space within which to operate. The standard Resolution applets, as well as being OCX's within other applications, are ActiveX.Exes (to run in Win95/98/NT) and ActiveDocuments (to run in Explorer). ActiveX Exe All applets are delivered to run as standalone ActiveX.Exes. ActiveDocument OCX applets can also be part of an ActiveDocument DHTML OCX applets can be part of a DHTML page VBA OCX applets can be used as part of a VBA script, such as a Resolver script, Microsoft Office script, OSI ProcessBook etc. Resolution does not replace a real-time database (RTDB) which is a highly tuned system specifically designed for collecting measurement data at high speeds and providing a graphical-user interface to that data. However a refinery or process plant has a significant number of categories of data that are NOT measurements. Efforts to ‘shoe-horn’ these other categories of data into the ‘tag-time-value’ structure of a RTDB are doomed to failure. Instead these data require specialized data structures that can only be provided by a relational structure. Management of this ‘other’ information is provided by Resolution. To avoid replication of the real-time data into Resolution, Relayer provides virtual access to any real-time data so that it appears to be replicated in Resolution-Repository, but in fact it is obtained on demand. Thus Resolution and a RTDB are complementary not mutually exclusive. A RTDB is a highly tuned system, but capable of storing only one type of data: the history of measurement values. Plant measurement data is an essential component to the business processes, but users and applications now require far more information than just measurements. This data has to be managed in a closely coupled database. Typical data includes planned future measurement values, equipment specifications, tank types, strapping tables, product specifications, movements, shipments and receipts, documents. RESOLUTION manages all of this data within one uniform, fully developed, database design. RESOLUTION comes complete with all of the required supporting code. Whilst there is no question that it is better to purchase an RTDB instead of developing one in-house, some still question the purchase of a standardized, implemented, relational, refinery data model. Instead they will propose the purchase of a relational database management system (RDBMS) and construct the tables, indices, stored procedures, and views themselves. They, then, have to create all of the data entry applications and reports to use this very specialized database design. Resolution’s plant model is significantly more comprehensive, more complete, more adaptable, and more fully implemented than any competitor. A plant model can be like a diagram of a complex process plant. There is a lot of work taking the plant 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. In reality, creating a site-specific relational database model is equivalent to writing a site specific RTDB. There are various techniques available to estimate the size of the task. One, using ‘function points’, estimates that one database entity is equivalent to 40 function points, which is, in turn equivalent to 5,000 lines of program code, or 0.5 man-years. Even a moderately complex refinery data-model will require significantly more than one entity. RESOLUTION contains over 100. There is another consequence of a site-specific relational data-model: the maintenance of the design once it has been installed. Typically, a database requires 15% of the original effort per year to keep up with users demands. If the design was specific to one site, then all of that effort must come from that site. If the design is standardized across many sites, as is RESOLUTION, then that cost is shared. There is some confusion over the role that a data-model of a plant performs. At one extreme, some regard a relational database as a ‘dumping’ ground for any data: if more data has to be stored then simply create another table to store that data. The database will certainly not lose this data, but users will not be able to create queries or reports on a database designed like this. The cornerstone of a good plant data-model is the capture of the refinery configuration. Therefore, there are database tables that: What does this mean? One advantage is that the production of a material balance for any unit in the plant uses exactly the same database report. The database knows what streams are flowing into or out of the unit from the information contained in the database. From this the database can deduce the mass or volume flows or whatever characteristic is required. Another advantage is that if any changes occur to the refinery flow-sheet, no reports whatsoever have to be re-coded. The changes have to be made once to the database and thereafter all reports will automatically reflect that change. Yet another benefit of a comprehensive data model is the way performance equations are implemented. If they are implemented in an RTDB, then each equation has to be re-written for every situation that it is used in. For example a heat exchanged efficiency calculation, when written in an RTDB, would require that all of the measurement tags be hard-coded into the equation. If the same equation were to be used for another heat exchanger then the whole equation would have to be repeated with new tag names. Alternatively, equations written in RESOLUTION can use the data-model to determine the same information given the heat exchanger name. Therefore, there is only one equation applied to many heat exchangers. This significantly reduces the equation management overhead. When data has to be manipulated manually, it is surprising how much additional information is supplied by the user of that information to make it usable in an application. For example, when a tag is retrieved from an RTDB the user has to deduce from the tag-name some or all of the following: All of this logic has to be written into the applications or reports that are processing this data.
RESOLUTION manages all of this additional information within the relational database data-model. Therefore, reports can be requested in a particular units-of-measure. RESOLUTION’s database queries will take care of conversion of all of the units-of-measure of the information from the RTDB. RESOLUTION also takes into account mixed units-of-measure. For example some streams can be measured in BPD or KL/D, whilst others are in MBPD or MKL/D or whatever. RESOLUTION allows direct requests for information, taking care of all of the additional information required providing an accurate and complete response. An example query would return the ‘averaged’ ‘planned’ ‘volume flow’ in ‘BPD’, for all of the ‘products’ from the ‘crude’ unit, averaged over the last ‘shift’. There are no program changes required to return the ‘total’ ‘actual’ ‘mass flow’ in ‘tonne’, for all of the ‘products’ from the ‘FCC’ unit, averaged over the last ‘week’. The equivalent in an RTDB would require substantial reprogramming. Resolution-Repository is designed to be entirely customizable. Virtually all of the customization can be achieved via data configuration without any programming whatsoever. The Repository database is designed to be entirely independent of any particular business process, yet it must meet all business requirements. Repository uses the Objective-SQL methodology to implement its flexible data model that encompasses the majority of data-behavior within a plant. Traditionally, relational models are created by identifying all of the different ‘entities’ within the scope of the proposed database system. For each entity, attributes and relationships with other entities are identified. As more entities are discovered, more tables are created along with the additional attributes and relationships. Making table and attribute changes to a database has a significant impact on the application design. Repository, and Objective-SQL, approaches this problem differently. Classes are created to model different types of behavior. A particular resource, or object, can then belong to as many classes as necessary to encompass the entire behavior of the resource. What does this mean? We have encountered and implemented every type of data behavior in the plant ensuring that the database design will not have to change to meet new requirements. Take for example a transfer line with significant internal inventory. In Repository, one would not find a single entity called ‘transfer-line-with-inventory’. Therefore, a particular transfer-line-with-inventory would belong to the following classes: Resource: Every object belongs to the Resource class. Membership of this class, which is automatic, allows the ‘transfer-line-with-inventory’ have attributes such as ‘line fill capacity’. These are managed within the Resource_Case_QPMCS(Criteria) relationship. Item: Membership of the Item class identifies that this particular resource exhibits the behavior of being a plant facility. Of particular relevance to ‘transfer-line-with-inventory’ resource, a member of the Item class may have material, or Commodity, contents at a particular time as identified by the Item_Case_Tick_Commodity relationship. This defines what Commodity(s) was in the Item at a particular time (Tick). Since there may be planned, actual, etc. versions of this information, Case is part of the same relationship. LineUpItem: A class that describes how material flows between two places. The source and destination would be BatteryLimitItems. Since this is a subset of Item, which is in turn a subset of Resource, membership of LineUpItem automatically provides Item membership. InventoryItem: All members of this class have inventory. Therefore, when accounting for the total material in a plant, the contents of all members of the InventoryItem class must be taken into account. The ‘transfer-line-with-inventory’ should be included in this class since it would have significant inventory. Another example of an entity might have an entirely different set of behaviors, for example metering pumps. The advantage of Objective-SQL, and the Repository implementation, is that such additional ‘entities’ do not require an additional database table, because membership of the different behavior classes of Repository is controlled entirely by data. Resolution includes one of the most comprehensive log-in and access options available with systems of this kind. User’s access, enabled by a single logon, determines which applications can be run, the menus that they will see, which database objects are accessible, and finally row-level ownership of data records. There is a uniform security policy enforced throughout RESOLUTION. First of all access is restricted to users with valid network and database logons. Secondly each user must be assigned privileges to access the particular application modules, stored procedures, and views. This also prevents access to particular applications within the RESOLVER suite of user interface applications. Finally, and this is a configuration option, ownership can be configured on any table within the database. What this means to the user is that each record within that table is 'owned' by a particular group. Members of that group may access this data unhindered, but members of other groups will have restricted access to that record, unless the owning group grants that permission. Therefore if ownership is configured for the sample table that contains all of the samples, then only users belonging to the owning group of a sample will be able to see that sample unless given access. The type of granted access is also controlled. For example, the owner might provide view only access, preventing another group changing that data. Any table within RESOLUTION may have auditing invoked. This then provides a history, record by record of any changes that were made and by whom. When audit/history is applied the time the change to the record occurred is recorded as well as the user who made the change. Additionally, they can be made to enter a reason for the change. The complete history of change can then be reconstructed using standard Resolution views and procedures. Thus the summary of features is: Audit: Any database object can have its auditing activated. When activated each record is automatically tagged with the user id and date/time. History: Any database object can have audit history activated. When activated each record is automatically tagged with the user id and date/time, and the old record is transferred to a companion table. The state of the database object at any time in the past can be automatically recovered via supplied database views. RTDB systems come complete with excellent graphical user interfaces. These GUI’s allow sites to create custom displays of their data. However, this data is largely limited to ‘view-only’ of the measurement data stored within the RTDB. Some RTDB GUI’s now allow access to data stored in relational databases via ODBC connections, but this is always ‘read-only’. The relational database required to complement the RTDB system is not going to contain static data. Nor will all of the data come from other systems such as the LP, scheduling system, reconciliation application et cetera. Therefore applications will have to be developed for the user to interact with the relational database to create new entries, read existing values, update those values, or delete data. RESOLUTION comes complete with over 100 user application screens for performing these tasks. This library is so comprehensive that it provides all of the user screens required to manage the hydrocarbon logistics in a refinery. Users want to write reports that contain data from a variety of sources. Tools of choice will be Excel, Crystal Reports, BusinessObjects, or other report writer. Although these tools them selves are easy to use, they are only as good as the organization of the data supplying the reports. In the case of an RTDB, the only data that is available is measurement history values. Therefore, ‘other’ data has to be stored in another database. This other database will require all of the supporting database views that re-assemble the underlying data into meaningful information. For example, RESOLUTION provides a single query that provides all of the following reports without any programming effort whatsoever: Implementing the same within a RTDB would require a completely separate report program to be written for each. This is just one example of the enhanced reporting of RESOLUTION. A RTDB performs the essential requirement of storing the real-time measurement data. If I want to write a report that involves both the real-time data and ‘other’ data such as planned movements there are two options: ODBC allows data to be brought from multiple data sources. ODBC is not performed in the database server. Instead, the ODBC query is executed within the client machine. This can result in exceptionally slow queries. The user also has to manage the differences between the different databases involved in the query. For example, one database might call the instrument ‘11:FI-107’, and another one calls it ‘11FI107’. ODBC cannot resolve these differences. Tools like CrystalReports and BusinessObjects cannot create a single query involving multiple ODBC data sources. So merging data from two different databases has to be done by a program. This is something well beyond an average user. RESOLUTION provides ‘virtual’ access to the real-time data. It appears that all of the real-time data is in the relational database. In fact it is not, and it is only transferred when a query requires the data, and is not stored within the relational database. This occurs automatically. All of the different naming conventions are automatically resolved by RESOLUTION, transparently to the user. A site may even have multiple and different RTDB systems in place simultaneously. Still RESOLUTION will resolve the location of the data and deliver it to the users. RESOLUTION also provides the ability to send data to the RTDB, enabling information from tools such as scheduling applications to be communicated to the RTDB when that plan becomes current. Therefore, RESOLUTION provides ‘one-stop’ shopping for all data. Resolution incorporates many ways of integrating with Excel, PowerPoint, and other MSOffice Products: Users are demanding reports that include data from multiple systems. For example, the actual production needs to be compared with the planned production. While the actual production measurements can be stored in an RTDB, planned production cannot. The reason for this is that RTDB systems only store current and past measurement values. Planned values, even if they can be translated to a measurement, are always in the future. Other application systems, such as reconciliation, planning LP, scheduling, process modeling systems, do not include databases for storing their data in the long term. The ‘outputs’ of these systems are not simple measurements. Therefore, to perform reports comparing planned versus actual, this data has to be transferred to a database. Take the example of an application such as inspection tracking. Looking at the data elements, there is an inspection point (tag), a time, and a value. One need then to perform a calculation to determine the corrosion rate and then compare this to the corrosion allowance which is part of the design specification data stored in RESOLUTION. If there is any significant corrosion taking place, there needs to be a quick evaluation to determine the root cause. The easiest way to facilitate this would be to have a relational database such as RESOLUTION relating all of the information required via a data-model to give a quick assessment. This would include operating data, temperatures, pressures, flows, et cetera, as well as laboratory data, and materials of construction. The results of the assessment should then be automatically sent out. Finally, the next inspection should be scheduled by sending a message to the Maintenance Management System via RELAYER. Resolution includes a comprehensive application suite built from the Resolution toolkit. These applications can be used ‘as-is’, but can also be adapted, even after they have been installed, to a clients specific application, interface, or work-flow requirements. Current solutions include: A solution that provides laboratory sample entry, scheduling, results capture, distribution of laboratory results directly to the real-time data historian or DCS, and the generation of certificates of quality. A solution for the creation of KPI’s, the underlying calculations, review of the KPI values, via a ‘drill-down’, to identify ‘bad actors’, and reports of the KPI’s actual, target, et cetera values. The yield accounting solution unifies unit material balance reporting with the expected yields and the yields reported by off-sites. The target setting solution includes entry of the unit operating targets, both operating characteristics and material movements, review of the plan or target, and the adoption of this target as settings for the control systems. The equipment inspection and testing application solution manages circuit drawings, test point locations, test scheduling, test data acquisition, test reporting, inspection scheduling, and inspection report management. This solutions is a central clearing house for all equipment specification data. The data, which can be interactively entered, updated, and reviewed, is stored in such a form that it is suitable for engineering analysis such as automatic comparison of design values versus measurement actual values for precisely the same characteristic. The REGISTRY master catalog already provides the catalog of ‘key-words’ against which to index any document. Any document about a piece of equipment, a plan, or a material, can be found using this solution. Additionally this solution knows of the location of that document and will retrieve it whether it is contained in an external EDMS system or stored directly within REPOSITORY. Off-site data management is built within the REPOSITORY database. This solution provides tools for reviewing and changing tank compositions, consolidated inventory reporting by area, and stock category, movement data entry, movement reporting, and inventory/material movement balancing. The majority of this solution is performed within the database, leaving only the reporting and data entry for the client-side application. The operator log-book solution provides a means for the control room operator to capture notes about the performance of the unit’s equipment, and the operation against plan. These notes, which can be in the form of documents, are all stored in the database keyed against the plan or unit so that they can be easily retrieved. The Solomon Performance Indices solution provides all of the Solomon Index parameters and calculations online. Indices are grouped in the same way as Solomon and, like Solomon, can be grouped for plant reports. RESOLUTION application solutions are not limited to these areas. Applications can be easily configured using the standard components to mold a solution to match the user's business requirements rather than the user having to adapt to a vendor's version of the process. Firstly this is a problem with some solutions, but it still has to be solved. The solutions range from the single, integrated, universal application, to automation of change-management. The Utopian Refinery Company, now bankrupt through excessive R&D expenditure, speculated on the creation of a shared, common, representation of the refinery. Unfortunately not all of the current applications would allow this; they each had their own, private representation best suited to their own purposes. The current, best compromise is to have a common reference mode, which is independent of the application systems themselves. Any changes to this common reference model can be communicated to the individual applications via, say, a message. It is then up to the interface on each of these applications to make the change. Some systems will allow this to happen automatically. Others require some form of manual intervention. If a message-based system is being used to communicate these changes, then there will be an in-box containing potential changes for each system. We can then take it further and give some application systems ownership of some of the data. Then, when they make model changes it is there responsibility to notify other systems. Again this is probably best achieved by messaging. Relayer makes maintenance of information in cooperating systems easy by allowing the system that owns the data to notify and information in other systems when new data is created or is needed by another system. Relayer messaging makes data required for and the information generated by applications available to other applications in a timely, consistent, standard, easily managed, guaranteed delivery, system. Relayer provides the site with true plug-and-play integration of applications. Any application attached via Relayer to the Resolution system does not need to know the specifics of any other applications. Relayer handles all of the messaging routing and translation. Thus, if a laboratory system becomes obsolete, another system can be put in its place and as long as the new system produces the same generic laboratory messages, and can respond to the same incoming messages, all other systems are totally unaware that the change has occurred. Relayer messaging is used to move messages and data between cooperating systems. The routing of these messages is entirely configurable. PL/SQL or VB scripts control the behavior of the agents that respond to the messages. If new data or business processes are needed, additional agents can be added or the sample scripts modified to change the way agents respond to messages. These elevates Relayer from just being a way of interfacing systems to be a combined system and business workflow management system. For example, completion of a business task can be signaled via a RELAYER message. This message is automatically propagated to all other applications that have registered an interest in this message. These other application systems are configured to respond to this message according to the client’s business rules. They might generate their own messages. For example the addition of a new document would create a message requesting that the document is indexed. A new laboratory sample might create a message distributing the sample results to all users. Another example is the change in configuration information in one system such as an instrument management system. The attached Relayer Listener can broadcast a message notifying other systems of this change, which in turn can update their own information. In this way Relayer automates the complex management-of-change process, greatly easing maintenance of information throughout the distributed applications. Clearly any database structure as large as RESOLUTION’s REPOSITORY database together with the RELAYER interfacing tools needs a large number of user interface screens in order to view and maintain the underlying data. RESOLVER meets that objective as follows: Avoid the creation of a single large application that performs all of the user interface functions from the single application. The reasons for avoiding such an application are the large executable size and hence performance, the difficulty in adapting the application to match changing requirements, the fact that the business process becomes ‘trapped’ within the processing logic of the application, or the application is too general to be of use. Create an environment that can adapt to changing business processes. The reason for this is that, just as REPOSITORY is designed to be as independent as possible of the business practices, the user interface should also be independent. Thus to modification of Resolver-based applications does not require reprogramming. Exploit the use of the ‘thin-client’ in which the majority of the data manipulation is performed on the server, while the user interface is left to perform the data presentation. The reason for this is that the user interface code becomes much smaller, the overall system performance increases, and changes to business data manipulation logic are largely confined to the database procedures which are stored in a single place and are hence easier to maintain. Allow the user as much flexibility as possible in creating their own environment and navigation routes between tasks, while providing the ability to define preferred navigation routes. The reason for this is that some user interfaces tend to fix the navigation path in such a way that they are unsuitable for many purposes and are not easy to maintain. Allow external applications to be integrated within the user interface architecture in an as-seamless manner as possible. The approach adopted is as follows: Each database task is implemented as an entirely independent application. Because these applications are significantly smaller in size and scope than the typical application they are referred to as RESOLVER APPLETS. These tasks are usually confined to operating on one, two, or maybe three closely related REPOSITORY tables. The majority of APPLETS are designed as operations on a particular class of resource. For example an ‘update an existing plan’ task can be regarded as an operation (or method to steal object-orientated design terminology) on the plan resource. Therefore all applets can take command line arguments that identify the database server and the resource upon which this applet operates. Navigation from the applet to perform other tasks is always performed via RESOLVING the resource rather than adding the additional code within the applet itself. RESOLVING allows a context sensitive menu to appear wherever there is a resource within an applet. ‘Right-clicking’ the resource brings up the menu. This configurable context sensitive menu will show all of the tasks that may be performed on that resource. This menu can include either other applets or third party applications. RESOLVER scripts are used to spawn other applets. When these applets are spawned from another applet they inherit the resource from the spawning applet. This, then, gives the appearance that the second applet is really part of the first even though it is an entirely separate executable. The database interface is via views for data retrieval, or via the new, updates, delete, and verify stored procedures for data manipulation. REGENERATOR generates all these database objects. Any more complex data manipulation that needs to be performed as a single transaction is by a specifically written database procedure or view. Resolver objects can be embedded into many of your favorite applications (MS Office, OSI ProcessBook, etc) to provide a direct link to Resolution data and hence all information. Common user interface requirements are implemented as OLE controls. This ensures the maximum amount of code sharing between individual applets. It also greatly reduces each applet’s code size. RTDB systems provide a common user and application interface to measurement data. The interfaces to the measurement systems are highly developed. Now plant information integration demands integration of other systems as well: planning, scheduling, reconciliation, financial, maintenance management systems, document management systems. RESOLUTION provides a standard interfacing solution, via the use of RELAYER message broker to handle these other types of systems with data structures that are very different from that managed by an RTDB. Where can a RTDB store a planned material movement between two locations, consisting of a particular grade of product of a certain specified quantities and qualities? RELAYER not only provides the interfaces, but also the tools required to manage these interfaces, the common reporting of errors, startup and shutdown, et cetera. Our focus is on the continued development of the Resolution technology to maintain our leadership. To deliver the product to our customers we have formed partnerships with the following companies, and have trained their own resources to undertake the implementation and support. These partnerships allow RIS to retain the technical agility and product commitment of a small company together with global presence, local support, and the trained project staff of our partners. RIS is a small, technology focused company. Our organization is very flat. Everyone is involved in all aspects of the Resolution product development and support to ensure consistency from requirements and design, through development, testing, release of product upgrades, and support. All other aspects of running the company: accounting, marketing, advertising etc are out-sourced. Our objective is to deliver any plant information to the desktop more efficiently and cost-effectively to enable improved decision-making and hence performance. We offer a strategic solution with a tactical budget and time-scale. RIS is deliberately focused on the single product: Resolution. Such focus brings commitment and dedication to both enhancement of the product and the service to the client. We believe that throughout our industry it is the smaller organizations that have been able to offer innovation, commitment, and focus. Conversely it is the larger organizations that have demonstrated lack of commitment to a product. After all, they have to respond to their shareholders who might not see the same priorities as the individuals in the organization. Unfortunately they sometimes see de-support of a product as a marketing ploy to encourage even more sales to a client. Resolution, as well as being a powerful system, is also very configurable. This enables it to meet many refinery application requirements. Thus our installed sites have all successfully taken advantage of Resolution in different ways: An operator of multiple offshore production platforms uses resolution to manage equipment and document data throughout the life cycle of that equipment. During the project phase, contractors directly enter all equipment specification data sheets into Resolution. They also have access to all documents via Resolution, even though the documents are stored in a document vault: Documentum. Security ensures that only those with the correct authorization may update or view data. Additionally, all changes are audited. During this phase, it is possible for the client to view the progress of the contractor in assigning datasheet values. When the project is handed over to the client, so is the data. However, no data is actually moved. Instead, the ownership of the data is transferred to the platform for which the project was executed. The same information is automatically shared with other systems: maintenance management system automatically notifies when equipment criteria are changed or equipment is added or relocated. A similar interface exists for the equipment inspection system and document management systems. Thus, the client provides to all of its users, both contractors and in-house, one-stop shopping for all equipment data. At one company, the largest private US refiner, they are using it at all of their refinery sites to ensure that the scheduling instructions coming from the scheduling system are being met. If there is a deviation to plan, operations report why this occurred and the remedial action required to avoid this in the future. In the first month of operation one of the sites broke 19 operating records, having never before broken more than one in a month. They are also building up a library of 'experience' that will no longer be lost when staff change position. This company continues to expand their use of Resolution. Resolution calculates and manages all of their key performance indicators, which now number over 2000. They are now adding all of the maintenance and expense charges to Resolution. The purpose is two-fold. Firstly, they wish to provide unit-by-unit, and code-by-code details that are not available from their financial or maintenance system. Secondly, they wish to expand the key performance indicators within Resolution to include the financial information. Another company, the second largest worldwide, is using Resolution to integrate all of its information systems: real-time data base, assay management, scheduling system, LP planning system, laboratory system, reconciliation system, and blend scheduling and optimization system. Having used Resolution to integrate these systems has enabled them to configure applications within Resolution as follows: automatic energy intensity index calculations; automatic gross refinery operating margin calculation; ship terminal management; yield accounting and reporting; and more. The same company is now adopting Resolution to manage all of the key performance indicators at all of its sites worldwide. This company has adopted Resolution as the recommendation for all sites. Another company, a national oil refiner, has been using Resolution successfully at all of their sites to consolidate the required information, and then calculate, all of the refinery and unit performance indicators: yields, unit margins, energy intensity indices, etc. Integration required interfacing to manual data collection systems, real-time databases, and laboratory systems. Building on this success they are now installing Resolution to manage all of the enterprise-wide information. With this they will have, automatically, a consolidated view of their performance: assays (they produce their own crude); refinery productions and consumptions; inventory position throughout the system; gross, net, operating, and accounting margins; operating expenses by unit, product, and category; maintenance and turnaround activities. With this information they will have one-stop-shopping for all performance indicators. Other sites show the flexibility of Resolution: A polyethylene plant uses it for managing all operational details including batch and lot tracking, inventory and production reporting, and laboratory details. A gas plant with only 8 people, illustrating that Resolution is not confined to large refineries, uses Resolution for all operational and environmental reporting. A wastewater recycle plant uses it for its operational data historian and reporting. |
|
|
||
|
|
  |
||
 |
Copyright 2003, Resolution Integration Solutions, Inc. Web Design & Development by  |
|
