In part 1, I introduced the concept of a portal between two KnowledgeScapes. The portal allows you to effectively import objects from one KnowledgeScape and use them as if they were local. This allows for some nice things. For example, if you wanted to create some neural network models to model the operation of some equipment, but you have rules running to control that equipment, you may not want the intensive nature of training the model to interfere with your rules. So for reliability you could create a new KnowledgeScape with a portal to the equipment in question, then build and train your model there.

We think that portals enable one of the more compelling concepts in supervisory control. One of the phrases that we used in early marketing material was "From control room to board room". To us this means that process control is simply the low level implementation of our business rules. And that means there is can be a true connection between the highest level business rules to the lowest level control at the processing plant. Portals enable the establishment of a hierarchical set of KnowledgeScapes, giving access to those who need it, and allowing for the rules processing to be done at various physical locations. It also provides robustness with regards to maintenance and failure, as the system can handle the opening and closing of portals dynamically. Perhaps an example can illustrate the point.

Imagine a typical mining company that produces copper and has operations in North and South America as well as Southeast Asia. Some of its operations ship concentrate to a company owned smelter, others sell to third party refiners. Each operation has different head grade, different power cost, different labor cost, and different transportation cost and distance to the the smelter and refinery. Each operation needs to first stabilize then optimize its operation. This is the responsibility of metallurgists and operators at the plant site. A KSX server is installed, and the control strategy runs locally, with personnel on-site given access to the system. Personnel at one plant cannot access other plants' strategies and servers. Regional and global changes in copper price, energy price and fuel price (transportation) change constantly. Supervisory, higher level KnowledgeScapes can be installed in places like Santiago, or Phoenix, that give regional management the opportunity to codify business rules that can in real time implement changes to the operating strategy. The regional KnowledgeScapes simply open portals to the local plant KnowledgeScapes, giving them access to the objects and data. Limits and production targets can be automatically adjusted. Access to the high level rules is given to the appropriate users. In the event that a plant does maintenance on its system, the portal closes, and rules accessing objects through the portal become inactive. When the system comes back, the portal automatically reopens, inactive rules become active again, and the system continues as before. If the regional system goes down, or if the network is not available, the local systems just run normally, using the limits and targets that they have. At any time in the corporate office, management can view real time trends of all of their operations world wide. Using the built in capabilities of KSX, you can build a system that is robust despite failure, controls access, distributes processing of rules and can utilize centralized resources.

Another great benefit of KSX's distributed functionality is that both computing and human resources can be shared across geographically diverse plants. Model training can be done on a cluster of computers maintained in a clean environment far removed from the plant, and maintained by a core set of engineers whose time and expertise can be shared among the plants. Many of our clients report great difficulty in recruiting then retaining high quality personnel when plant sites are very remote. With KSX and portals, it's easy to establish a service center for support, yet still allow the core strategies to be located on site, close to processes they control. Portals also allow for reporting, data-mining and modeling to be done on third party resources like the Amazon Elastic Computing Cloud (EC2). Jobs can be run as batches against plant objects and data, then shut down, saving on valuable infrastructure, and allowing elastic scaling of resources.

Using portals is a great way to design a robust distributed system for hierarchical supervisory control. It is a key piece of the KSX distributed computing architecture, but there is still one more piece to describe. In the next post I'll talk about how KSX uses computing slaves to automatically parallelize tasks and take advantage of multi-core machines and clusters of machines for its optimization tasks.