Multiple projects on one server?

[zscriven]

I am designing a system for a client. They have two different processes and I am wondering what would be the best way to setup the architecture.

• Currently they have a server managing their CNC machines and they would like to add a separate furnace process to WinCC OA.
  
  These dozen or so furnaces would each have a dedicated client showing status and control for the furnace it's next to.
  
  Also a manager can launch a client and look at all of the furnaces in an overview. This same manager may also want to view the CNC machines.
  
  What would be the best architecture? Is this a separate server? A separate project on the same server? Or a single project with navigation between different parts of the system?

Any advice from experience is greatly appreciated. I want to design a bad ass system. :side:

[fmulder]

Having multiple servers would mean that you need dist. Although dist works very well, it does add complexity to your project. And complexity means time, money. maintenance, more design etc..
There's nothing as simple as a simple server (which means simple application)

When your I/O count is reasonable, then I would always suggest to make a single WinCC OA project containing all the panels for both types of machine (CNC and furnace).

Running multiple projects on the same computer, still means that you introduce dist.

When your goal is to make a 'simple' (which means good) application then I see two options:

1) Combine the 2 applications into one WinCC Oa project (use areas or permissions to clearly separate)
2) Make 2 WinCc Oa applications and keep them completely separated (no dist). Just give your operator two icons on his dektop

When your application grows bigger in I/O or geographical locations, then dist is the way to go

[leoknipp]

Hello,

please note that running several projects on one server is prohibited.
This is also documented in the WinCC OA online help.

Best Regards
Leopold Knipp
Senior Support Specialist

[RudiKreiner]

I couln't find the reference in the online help that prohibits this.

We used to run several projects on one server during project development, just to save resources, and that seemed to work OK, but that was with older PVSS versions.
For our live systems we always had one server for one project.

Now we have a virtual machine for each project during development to be more modular and flexible, so this is no longer an issue.

[leoknipp]

Hello,

in the WinCC OA help for 3.14 (using the newest patch P005) you will find the following information (Project administration --> Project administration --> Requirements and Installation).
Only one WinCC OA project is allowed to run on a system! Multiple project must not be used on the same machine!

The same information will also be included in other parts of the documentation or documents delivered with a WinCC OA version.

Best Regards
Leopold Knipp
Senior Support Specialist

[zscriven]

Frenk Mulder wrote:

Having multiple servers would mean that you need dist. Although dist works very well, it does add complexity to your project. And complexity means time, money. maintenance, more design etc..
There's nothing as simple as a simple server (which means simple application)

When your I/O count is reasonable, then I would always suggest to make a single WinCC OA project containing all the panels for both types of machine (CNC and furnace).

Running multiple projects on the same computer, still means that you introduce dist.

When your goal is to make a 'simple' (which means good) application then I see two options:

1) Combine the 2 applications into one WinCC Oa project (use areas or permissions to clearly separate)
2) Make 2 WinCc Oa applications and keep them completely separated (no dist). Just give your operator two icons on his dektop

When your application grows bigger in I/O or geographical locations, then dist is the way to go

Good luck and share the fun
Frenk Mulder

Thanks for the advice! I like the single project / server approach.

This does bring me to my next question. For the CNC application I am developing for the client.

- The sales engineer decided it would be a good idea to purchase 4 128 i/o server licenses (one for each CNC machine) and one central server 1000 i/o to run a distributed setup for management.
- The network is solid so I can't see any reason why this is a good architecture. I'd much prefer to develop a single server application and have 4 client licenses to run an HMI application for each CNC machine.
- Appearantly this was somehow less expensive from a licensing perspective to buy 4x 128 i/o server licenses rather than just buying 4 client licenses!
- I am really dreading developing this / maintaining it. I've setup a dist exactly like this before, Actually that's how we demonstrated the software to the client. I really just think it's not a good idea.
- I imagine the dev / maintenance time would outweigh whatever licensing savings there is. And it's just seems like bad practice for what should be a simple application.
- Any thoughts? Opinions? Or suggestions?

[fmulder]

Dist is ok when you stick to standard stuff. When you just use it to:

1) Visualise data from a remote system
2) Use the standard AES screen to display alarms

When you implement more complex stuff, like a script that synchronizes datapoints (example : permissions) then it tuns out more difficult that you think. We implemented a status icon that display the summed status of N remote dist systems. The complexity is caused because the individual connectios can drop. The script that we wrote it not very simple !

So there is no simple answer. If your application is simple, only using standard screens, then you're probably ok. If you plan to make complex central logic, then reconsider

Note that you'll have to pay for dist 4 times.
I would estimate that one server with 4 clients is probably 'cheaper' (when you calculate the complexity of the dist)

[Gertjan van Schijndel]

Another option would be to use standalone projects on the machines (as local HMI) and a central server, which also reads the data directly from the machines.
This way you cannot access central server data from the machines and in case of local HMI failure can still control the machine from the central server.