In my last post, I started to outline some of the problems that distributed computing can solve. In this post I will give some specific examples in process control, and start to layout the first part of the solution using KSX. Traditionally the expert control strategy for controlling a plant was contained in one monolithic configuration, or "KnowledgeScape". For many plants and processes this works very well, there is more than enough computing power to process the rules. But there were some occasions where keeping everything altogether becomes unwieldy. Some plants, rather than have 2 large mills to control, have 32 small mills. Some plants rather than have 60 large flotation cells, have 400 small ones. In these cases, having everything packed together can start to present problems, if not processing, then certainly in organization. Then what happens when you want a neural network model for each mill? Or more than one model, and an optimizer? All of the sudden you have a processing load that starts to become unwieldy. How to deal with it?

One solution is to simply separate out components. In the database world this is called "sharding". As in break your monolith into shards. In our example, the solution could be to have a separate "KnowledgeScape" for the flotation plant, and for the grinding plant. In a web application, it could mean having a separate database for customers A-H, and for customers I-Z for example. This is certainly a widely used technique, and is the only one available from our competitors. It can also be done easily with KSX. If fact, the KSX client can connect to multiple KSX servers or "KnowledgeScapes" at the same time. You can drag and drop objects between them, and easily navigate. But this is only the first step in a unified distributed computing solution. There remain other problems to solve. If you have divided the grinding plant into two KnowledgeScapes you don't want have to make the same change twice if you modify a rule. And if the KnowledgeScape where the flotation plant rules reside, needs information from the grinding plant KnowledgeScape, how does it get it? And what happens when you want to write rules at a higher level still, implementing enterprise wide rules that affect multiple plants? KSX goes beyond just simple sharding and enables you to separate operations onto different computers at different locations, yet still configure the system as one, and still implement rules in one KnowledgeScape than can use data and invoke rules in other KnowledgeScapes. We created a special object in KSX called a "Portal". It lets you step into remote KnowledgeScapes and interact with their objects as if they were local. They're very special, and will be the subject of the next post.