Lot of our customers require a centralized solution across multiple plants. The reason usually is that the customer wants to have the overview and control of every plant, and also to minimize the effort needed for installation and configuration in every other plant.
There is a “master plant” and various sub-plants. In other cities/countries/regions around the world.
Most customer at first thinks that the best and easiest solution is to make the main server installation at the master plant and in every other plant only clients will be distributed.
This idea will usually fail because a classic client has too long startup times when clients are connected from 1 part of the world to the main server at master plant. The applications (*.exe) and all data must be started from the server.
Alternative idea, also often thought about at first, is during the client installation, the program parts are stored locally. This saves some time when starting up, but accessing the database takes time. The update of the individual clients must be done per client when new versions are released.
The next option would be to design the distribution of clients at WTS / Citrix. The basic requirement here is: The customer is responsible for the platform! Q-DAS/Hexagon does not help with setting up Citrix.
If this is the case, the “clients” can be started via Citrix. There are various options here, e.g. depending on whether it is a terminal or a terminal server farm. Such a “client” is then started by the actual user via a “launcher”. When the software is delivered, a *.txt file with a PDF is included in which the batch commands are explained so that a “client” via Citrix also follows the classic process. Each client needs its own *.INI file per product. This is then implemented via the batch file.
Technically, environments set up like this can work. But everyday functioning within this system arises a question about administration. Usually, this ends up with need of support from us.
If everything (regardless of the technology) is installed as a server client, the data on the server will be used by everyone. The use of common databases and files across many plants must be questioned.
License database for multiple plants
A very interesting idea. The problem might be that, depending on the number of licenses, users from different plants will complain that there are no free licenses left. The question then arises for support as to whether “emergency licenses” can be blocked per plant. This is however not possible. Sometimes that can end up in users starting the software first thing in the morning to “block” their licenses, and maybe shorten the startup time when the technical implementation is bad (the author was on the hotline for years and got this exact explanation from users).
Configuration database / configurations for multiple plants
Sharing the configuration also sounds promising at first. A responsible in master plant thinks about the strategy to be used, the alarms, the mathematics, the reports. At the beginning, this is accepted in the sub-plants. Until special requests arise by the individual plants. Different reports are needed, different masks, different strategies. The larger a system with a single configuration, the more such a system becomes sluggish, and cannot respond to the wishes or requirements of the users of the individual plants (and their customers).
A solution to all of these questions would be to create parallel “plants” (if there are to be separations, and that is ALWAYS the case), if the platform and the internal IT service should remain in the master plant. The Q-DAS application engineers have a tool at their disposal to create multiple “plants” during a server installation.
This would mean that, whether in the classic server client or when distributing via Citrix, the “platform” would be common, but separated per plant.
And at that point the question can be asked why it was “centralized”!!! The only valid reason is that the IT services are tied to 1 place for “global” support. If this is not the case, server-client installation per plant, with individual key users per plant cooperating with each other, exchanging ideas, is the better solution.