When to use "Included Projects" and "Clusters"

The best thing is to use a combination of Include and Clusters.
I guess you have tags with the same name in both project. By using cluster you can distinguish between them.

This would need some re-engineering. If you have the same functions in both projects, one of them has to be removed. Are the original projects just one big project or is it already split up in a run, area, include and communications project. How sure are you that the machines are 100% identical? The Cicode and graphics library (symbols, genies and popups) should go into the library project. Is this for a global client or is the application supposed to run as one server, instead of two? Are the graphics developed using the equipment.item notation?

A cluster basically equates to a physical server (Reports, Alarms, Trends, and I/O), with an optional backup server computer and possibly extra I/O server computers. You can split the server features onto multiple machines, but with modern servers that's normally not necessary. So, a cluster is normally one or two server class machines. You could have that one cluster handle your entire plant. However, you may want to split it into separate clusters for a few reasons:

• Your server can't handle the load. Normally tuning the project and/or upgrading the PC will fix this.
• Parts of the plant are managed by different people who want to edit the project and restart the server without affecting each other
• Part of the system is critical that it not be interrupted by project changes/server restarts
• Part of the system is in a physically separate area, such as a different building or campus, and needs to have its own local server to keep running in case the WAN connection fails.
• There is local serial I/O or other data networks (like Modbus Plus) that cannot easily be extended to physically connect to one central pair of servers. In this case you could just add an I/O server computer to the existing cluster.

When to use included projects would be: When it makes sense for your own organizing and the way you edit the projects.

Why do you want to include the projects together? Here are some possible reasons:

1. You definitely can create a global/master project that includes both Machine1 and Machine2, but it can be a lot of work to fix all the conflicts if the projects weren't designed for this and have a lot of duplications. It would only make sense to do this if you want to have a global client that can see both machines at the same time without having to shut down and switch projects. The structure would be:

Global
   Machine1
   Machine2

In this case, on each machine, you could run either the machine project or the global project, depending on whether you needed to see both machines from each other. This would double the point count. If you just run the machine project on the machine servers, then run the global project on the global client, then you would only need the larger license on the client (which is cheaper).

2. If you just want to reduce the effort to edit the projects and keep them identical to each other, then it would make more sense to keep them separate, but make a Common, or library, project, as Bas mentioned, and move everything that is common to both projects into there. For example, identical pages, Cicode functions, page templates, genies, symbol libraries, labels, etc. Then, whenever you make a change to the Common project, just copy it to both machines to keep them in sync (and re-compile the main project). Your include structure would look like this:

Machine1
   Common

Machine2
   Common

3. Another possibility is that you need to share some information between Machine1 and Machine2. For example, Machine1 needs to read a few variables from Machine2 to do some calculations, and vice-versa. You can accomplish that by moving all the I/O definitions (I/O Servers, Boards, Ports, I/O Devices, Variable Tags) from both Machine1 and Machine2 into a Comms project and including that in Machine1 and Machine2. That way, each machine knows about all the tags of the other machine and can access them, but doesn't have any conflicts with anything else in the other project. The Include structure would be:

Machine1
  Comms

Machine2
   Comms

Or, you could create a separate Comms project for each machine, but it's not necessary in this simple example. I have seen this for plants that had many different servers that each needed to share data with some, but not all other servers.

Machine1
  Machine1Comms
  Machine2Comms

Machine2
  Machine1Comms
  Machine2Comms

4. Just to give you one more option...There is a rarely used feature called Cluster Replication. The idea is that you have many machines, all identical, but each running as separate clusters/servers. You create one project with one set of pages and tags, but define a separate cluster name for each machine. You enable the [General]ClusterReplication parameter and all tags are connected to all clusters as if you had defined the tags multiple times. When you open a page, you just specify which cluster you want to associate it with, and it connects to the tags of that cluster (server). You'd have to check with tech support for more information about this setup.

See the Citect Help topic: About Citect SCADA > Typical System Scenarios for more information about these and some other specialized clustering options.

Thank you kindly for the replies. Makes a lot more sense now