System Architecture Diagram
The OPCGatewayEngine does not contain any points. Its function is to serve as an OPC Server that makes points from other engines (typically GEMarkVEngine) available to various OPC Clients (i.e. Softing SOClient, Cimplicity HMI, etc.). The OPCGatewayEngine.tree file contains a list of all the points (from other engines) that will be made available to OPC clients via the OPCGatewayEngine’s OPC server. Thus, all the OPCGatewayEngine does is make points from other SIM4ME engines available to OPC clients. It is, as its name suggests, simply a ‘gateway’.
In the OPCGatewayEngine.tree file, prefixes are added to each point in order to associate a point with its engine. The ‘prefix_to_engine’ command line option determines which prefixes go with which engine. For example, if the ‘prefix_to_engine’ option is set as
-prefix_to_engine “M1_ Main_MarkVEngine”
it means that all points that are prefixed with “M1_” in the tree file are found in the engine named “Main_MarkVEngine”. The OPCGatewayEngine.tree file would list the points in this engine as “M1_pointname”. If, for example, the pointname is TNH1, the listing in the tree file would be M1_TNH1. Note that there is no actual point in any engine called M1_TNH1, there is only a point called TNH1 and it resides in the Main_MarkVEngine (as indicated by the M1_ prefix).
The OPC protocol supports two-way communication (when thus configured). This means that the server can write to the client, and the client can write to the server. In other words, the source engine can send data to the OPC client, AND the OPC client can manipulate data in the source engine (i.e. both clients and servers can send and receive data).
Installation Guide
The OPCGatewayEngine is installed through the Dynsim OTS Engines install shield. The installer will ensure that all the relevant files are installed, registered where appropriate.
After installation via the install shield, the following steps must be completed before the OPCGatewayEngine can be used effectively.
- OPCGatewayEngine must be registered
- OPCGatewayEngine *.tree and *.env files must be created / configured
- The OPCGatewayEngine must be configured in the SIM4ME environment
- DCOMCNFG settings must be appropriately configured for OPC server and client machines.
- OPC and Dynsim related services on server and client machines must be appropriately configured.
All of these steps are outlined in the User Guide below.
User Guide
Registering the OPCGateway
After installing the OPCGatewayEngine, the setup_OPCGateway.bat script must be modified for the machine that is being used and run. The locations of DLLs will be different for XP and 2000 machines. Modify the bat file appropriately and run it. This setup script only needs to be run once. It is found in .\Engines\OPCGateway\Bin. Before running this script, be sure top check that the path to the OpcGatewayEngine.exe (first line of the script) is correct. If it is not correct, fix it before running. While running the script, an SOProxy.dll error will occur. This is OK.
OPCGatewayEngine.tree and .env files
The OPCGatewayEngine_sample.tree and OPCGatewayEngine_sample.env files in the .\Engines\OPCGateway\System directory are only sample files. Delete them or replace them with the proper project files before running (see below for more information). The .\System directory is a good place for the *.tree and *.env files, but they can reside where ever the user desires to put them. If *.tree and *.env files are used (they are not necessary in every application) be sure to specify the location of these files via the Engine Configuration dialog box in the GUI.
An OPCGatewayEngine.env file will not be necessary for every application. If it is necessary, modify it as appropriate. The *.env file should point to the computer on which the simulation is run. An OPCGatewayEngine.tree file is necessary for every application. The tree file determines which points are made available to OPC Clients (i.e. Cimplicity) via the OPCGatewayEngine OPC server. Create a tree file that is appropriate for your application. If you are running Cimplicity (as in the Wansley project) a good way to come up with a list of points is to look at the ‘points tree’ in plant’s unmodified Cimplicity project file (see Cimplicity notes.doc).
If you are running OPCGatewayEngine with a GEMarkVEngine(s) (which is most likely the case) all the points made available to the Cimplicity OPC client will be coming from the GEMarkVEngine. Make sure that all the points you want to see are actually initialized by the GEMarkVEngine. You don’t necessarily need to check point by point. You can take your best shot at the OPCGatewayEngine.tree file by using the Cimplicity ‘points tree’. Once this is done, run a model with the GEMarkVEngine(s) and the OPCGatewayEngine. If you have followed the instructions below and in “Cimplicity notes.doc” carefully, points from the source engine (GEMarkV in this case) should be visible in the Cimplicity interface (or other OPC Client). Check that the communication is valid by changing a value on the server side (in the SIM4ME glossary) and making sure that it changes on the client side (Cimplicity, Softing, etc.) Once communication has been established, it is easy to determine which points are not initialized properly (by either GEMarkV or OPCGateway) because they will appear as either *** or garbage numbers in the Cimplicity interface. Add these points to the tree file, and restart the model.
Another important thing about the tree file is that point types listed in the OPCGatewayEngine.tree file must correspond to point types that the OPC client is expecting. If, for example, the OPCGatewayEngine serves up TNH1 as a real, but the client is expecting a bool, there will be problems. Double check the point types in the OPCGatewayEngine.tree file with the plant’s unmodified (original) configuration files (for the Wansley project, this means double checking point types in the Cimplicity project file (under the ‘points tree’) and in the GEMarkV ‘Unitdata.dat’ file.)
Configuring the OPCGatewayEngine in the SIM4ME Environment
1) Install the OPCGatewayEngine via the install shield
2) Create a simulation with an OPCGatewayEngine, or open an existing *.s4m file that contains an OPCGatewayEngine.
3) Highlight the simulation and open the ‘Simulation Configuration’ dialogue box
4) Highlight the OPCGatewayEngine and open its ‘Engine Configuration’ dialogue box
5) You will need to set several values in the ‘Engine Configuration’ dialogue box
a. Set the location for the IC and Backtrack files
b. Set an appropriate Synchronization period
c. Set the directory path for OPCGatewayEngine configuration files (this should point to the directory where the *.tree and *.env files are)
d. Set the ‘Engine name to prefix table’ value. The engine names associated with each prefix must exactly match (case sensitive) the engine names in the ‘Simulation Configuration’ dialogue box.
i. For the Wansley project this entry was:
M1_ Main_MarkVEngine S1_ BFPT_MarkVEngine
ii. The “M1_” and “S1_” are the prefix values that are placed before point names in the OPCGatewayEngine.tree file so that the OPCGatewayEngine knows where to look (i.e. in which engine) for a particular point. For example, say there is a point in the Main_MarkVEngine called “TNH1”. This point exists as TNH1 in the Main_MarkVEngine and can be called up in the SIM4ME glossary by entering either TNH1 or Main_MarkVEngine##TNH1. The EngineName## specifier only needs to be used in the glossary if there is another point by the same name in another engine. In the OPCGatewayEngine.tree file, the Main_MarkVEngine TNH1 point will be called M1_TNH1 so that the OPCGatewayEngine knows that TNH1 comes from the Main_MarkVEngine. There is no actual point called M1_TNH1 as the prefix is used only in the initialization of the OPCGatewayEngine and then it is dropped. This means the point is served up as TNH1 and an OPC Client will be looking for a point called TNH1, not M1_TNH1.
e. Set the ‘Delay in seconds to wait for other engines to start’. This is a very important option that must be set correctly in order for the OPCGatewayEngine to have access to all the points it is to make available via its OPC Server. For the OPCGatewayEngine, “OPC Gateway I/O started” indicates that the OPCGateway initialization is complete. This message cannot appear until after all the engines listed in the ‘prefix_to_engine’ option have completed their initialization. That is to say that any engines from which points will be made available through the OPC server need to complete their initialization before the OPCGatewayEngine initializes the OPC server. For the Wansley project, 60 seconds was plenty of time to allow the GEMarkVEngines to complete their initialization. This will, of course, vary from computer to computer and project to project. If the delay time is not set properly, some points will look fine on the client side, while others will be garbage.
f. DEVELOPER NOTE from N. Schmid: I modified the OPCGatewayEngine so as to remove the need for the wait time, but it was a bit unstable and we didn’t have the time and resources to test it out. I checked the file in to source control as “OPCGatewayEngine_no_wait.cpp”. Basically what I did was make the OPCGatewayEngine initialize the server on the first time step – which is necessarily after all the engines were initialized. Unfortunately, this also meant that the OPC client had to be initialized after the first time step. If and when the OPCGatewayEngine is used again, we may want to spend a little time seeing if we come up with a robust way of initializing the OPC server without a ‘wait_time’ command line option.
6) In order for the OPC server and clients to interact with one another successfully the DCOMCNFG and Services settings must be correct. See the sections below for more.
http://www.cadfamily.com/html/Article/Dynsim%20OPCGatewayEngine-Software%20Documentation_997_1.htm
http://www.cadfamily.com/html/Article/Dynsim%20OPCGatewayEngine-Software%20Documentation_997_2.htm
No comments:
Post a Comment