I have Analyzer which connects to a computer with cat5 cables . This Computer reads the data through a software called ComVisioner .ComVisioner has two Modes, one is Server Mode and Other is Client Mode A Server software acts as the engine in the system, providing one or more clients with information.
Server version is installed on a single computer . Once Server version is installed it collects data, performs calculations, produce reports and so on.
The ComVisioner client runs in the same computer as the server. Other clients can access the same single server through a network, providing that the software license allows more than one client at the same time
so there is Two client computers who access the as mentioned above .this all connection is done by Network cables . This part is fine
As License of Client is very expensive our company wants to add a OPC software so that more user can acquire data .As i have no knowledge on Opc part please suggest me How can i do it ?. what sort of software should i use ?. Can i install this software different pc with is connected in same network
There is also one more software installed in that computer which pushes the data as Modbus protocol
First, you need to make sure that the ComVisioner can give OPC data. (work like opc server). This should be indicated in the documentation.
Download the free OPC client, and make sure you can read the data (for example you can use, matrikon opc explorer or kepware quick client (I like it more, it goes together with KepServerEx, to download them you need to register)
If you can connect and see the data, then there will be no problems with access to the data. Next you need to find a solution for which Opc client suits you. Probably some SCADA system, but some good SCADA also cost a lot, and require a lot of development time.
I don't recommend you try to use modbus if there is opc. If you will use modbus you will have many problem with addressing and value format.
ps
We had a problem with expensive licenses. As a result, we solved the problem by give access for programm for clients via RDP (remote desktop connection)
Related
Has anyone seen anything on Windows Server 2019 that would prevent browsing the network in a Active Directory domain environment to find available OPC servers on remote hosts when all other OPC communications seem to be functioning normally and file share browsing seems to also be functioning?
There is something I'm missing here, but I cannot find it. Since the core OPC functions are working, tools like OPC Expert are not showing any errors and guides for DCOM settings from OSIsoft, KEPware, and OSI Institute are all being used to no avail. None of the DCOM settings seem to be addressing the CLSID network browsing. If a client has the ability to supply a remote host and query that host, the OPC services enumeration works just fine. The problem is that we are attempting to use clients that do not have any features to manually define the servers and solely relies on the network browsing functions.
Please tell me someone else has seen this behavior. I suspect that it is some network security feature of Windows Server 2019, but I can't find any documentation that points to what might be causing this function to fail. Worse, the function is completing normally, but with zero results, so I don't even have error messages to track the issue down with.
It really depends on the application you are using. There are many ways for an OPC Client to find the remote OPC Server. Most clients will use a combination of the folowing:
OPCEnum. In particular the heavy lifting is done using EnumClassesOfCategories which is part of Component categories Manager. Does not crawl through registry.
GetOPCServers(). This is a method is available as part of an interface called IOPCAutoServer which comes from the OPC foundation itself (via OPCDAAuto.dll)
CLSIDFromProgID() first to get the CLSID and then does the CoCreateInstanceEx().
When CLSIDFromProgID() fails, it falls back to using OPCEnum to list all OPC servers before making a connection.
That means that you would first need to find out what your client application is using to list the OPC Servers.
Then, on the Windows Security side of things, depending on the OS version of both nodes, you may need to disable Simple File Sharing mode (that is the case for Windows XP and older)
If it uses OPCEnum, you will need to configure DCOM for OPCEnum as well, which is the recommended method to list remote OPC Servers.
If the application only supports remote registry lookup to find the OPC Server, then you will need to grant access to the account connecting from the client to the Server
I am using OPC Foundation's OpcNetApi.dll to communicate with an OPC DA server.
I am curious if there is a programatic way to kill specific connections which are currently active on the server using this library or a similar library.
I'm not positive, but I don't think what you are asking for is always possible (without a debugger). OPC is based on Microsoft COM. There are two ways that COM can be implemented:in-proc and out-of-proc. The choice depends on the OPC server vendor.
With an in-proc implementation, if you are running the OPC client on the same machine as the OPC server then the OPC server is just a dll that is loaded directly into the memory space of the OPC client. This dll exposes the OPC interfaces like CreateGroup, ReadAllItems, etc. Now it is probably getting the actual data through some other mechanism (named pipe, TCP/IP, etc) but this depends again on the OPC server implementation. The only way to really force stop this OPC server is to end the OPC client or get the OPC client program. Of course the OPC client or OPC server may already have implemented a mechanism to end, but there is not guarantee.
If it is an out-of-proc OPC implementation then the OPC server will run in a separate executable so you can find the name of that executable and terminate it. (You can search in regedit for the name of the OPC server to find the corresponding executable name). If I remember correctly, the OPC server can be designed so all clients share one executable or each OPC client gets their own instance of the executable.
If you are running the OPC server remotely then it is probably going to be loaded inside of a stub program if its an in-proc implementation and then tied to RPC. If you block the ports that RPC communicates over I think most clients would decide to disconnect after a while, although there is no guarentee they won't try to reconnect later.
Here's some more information:
https://www.opcsupport.com/link/portal/4164/4590/Article/711/May-I-get-a-In-Proc-and-Out-Of-Proc-explanation
Given these 2 installations:
A machine with 3 OPC UA servers.
A machine with 3 OPC UA servers and a LDS.
What is the difference in functionality? In particular, I would like to know:
Is the installation of a LDS mandatory?
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
What does installing an LDS enable to do?
(All this, with proper OPC UA specification references where applicable, please)
Is the installation of a LDS mandatory?
No, the installation of an LDS is purely optional. Especially on small / embedded devices you might not even be able to install anything else than the OPC UA server.
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
With the LDS running on a standarized port (4840) it is possible to discover all servers on the computer without knowing their endpoint URLs. Without an
LDS there is no way to connect to a server without knowing the URL.
As already commented, having the LDS makes discovery (very) slightly slower, as a connection to both LDS and server has to be established.
If only one server is running on the computer one might want to set the port of this server to 4840, so clients discovering on the computer find the server without needing to know a custom port.
What does installing an LDS enable to do?
It simply allows to discover all servers running on the computer without knowing all their different endpoint URLs.
Future versions will contain enhancements, broadcasting this information via Zeroconf, so every LDS would have the list of all OPC UA servers on the local network.
We have acquired a 4 channel GSM Gateway, model GoIPx4-G610 (the manual is titled "GoIP Series SIM Card for GSM Voice Gateway - GSM VOIP Gateway").
We are looking to develop a custom application to control the GOIP gateway. We have developed in the past custom applications that controlled simple GSM modems through AT commands for sending/receiving SMS messages in particular.
Although the gateway can be controlled through SIP we would like to control the GSM modems embedded in the gateway through AT commands if possible. This is because of the fine grained control AT commands offer and because we do not need VoIP features since we need only to send/receive SMS messages.
The gateway runs an unknown Linux instance to which we can connect through telnet. Unfortunately we do not have the credentials to authenticate to it. The gateway also has a web http administration interface to which we can authenticate but we can't find there settings/information related to channels that we can use for AT commands.
The documentation is very poor and the provider could not offer us any helpful information regarding this.
If anyone knows how we can send AT commands to the modems inside the gateway it is highly appreciated.
Up to now we have tried a brute force attack on the telnet interface to find the credentials with no success. We hope that once we can connect to the Linux instance driving the gateway we can connect from there to the modems through serial connections (to send AT commands) and we can reconfigure it to redirect the connections outside of the modem or to make an interface for sending commands to the modems.
The device has an update firmware option (through the web interface) which always gives the error "download failed". Downloaded the firmware (.pkg file) manually from their update pages and extracted the files from the embedded Linux distribution that should correspond to the ones placed on the gateway. The files were kept in the pkg file as an ROMFS compressed image which we mounted on a test station to see the files (probably the running OS on the gateway is an uClinux distribution).
Did this hoping that we can find there the /etc/passwd file which could be cracked with classic attack. However didn't found it and probably that file is placed on the gateway flash memory (contrary to the Linux files which are stored on the ROM memory). So if there is a way to erase / reset this flash memory that could be a solution (in case the gateway doesn't refuse to boot without those files). Another solution would be to be able to access the flash memory with the passwd file if there is such thing.
You might take the lid off and see what parts are inside.
If it's a general purpose processor with a published data sheet and without a lot of code security features, you might be in luck. For example, you might find:
By guessing headers or tracing from known pins, a console serial port, either logic level or RS232, hopefully with a shell listening
A boot mode pin for the micro connected to a resistor, which you could jumper to cause the micro to boot to a uart bootloader where you could download a new system image, or patch the existing one. If you are lucky the bootloader would be something known, like u-boot.
A JTAG port for the processor
A removable storage device which you could remove and alter
an SPI flash which you could carefully tap into and alter
A flash chip which you could desolder and transplant to a programmer
You could also make a GPL sources request for the kernel and whatever else from the vendor. Or even just trying to identify versions of things like a web server could help you look up any known exploits. Since it seems you have a similar system image to that which is installed, looking through it could be helpful - look for additional daemons running, listening on ports you weren't previously aware of, left over debug support, etc.
I am the developer of the GoIP you've purchased. Instead of trying to hack the GoIP, did you contact us to support your development of custom applications? Here are the updates of GoIP for you.
GoIP now supports SMPP. This could be an alternative to using AT commands to send and receive SMS.
API (Application Programming Interface) for GoIP is now available to support your custom application development.
If AT commands are still the preferred method, please contact us and I would be happy to discuss with you further.
We can't get our PLC to reliably connect with KEPServerEX (OPC).
I was wondering if anyone else here at SOF has experience working with PLC and OPC. If so do they have any tips on making a reliable connection with our OPC Server. We currently use KEPServerEX for our OPC, but if anyone knows a better program to use we are open to suggestions.
I use Kepware OPC server for MODBUS TCP, Simatic S7 and Yokogawa for more then 5 years on 4 servers in industrial environment without any problems. It was easy to set up and showed no problems during exploatation. Actually, it was so nice that we decided to not use it only when it doesn't support the device we have (which is rare, and mostly happens when I have to develop custom OPC server). Kepware OPC server is even able to use reserved PG connection for connection to Siemens PLCs (unlike Simatic OPC Server, this is good if you have limited number of connections like in CP343 LEAN version communication module). It will also save you $$$$$ if you use data from it in some historian like OsiSoft PI which charges per OPC server connections, since all Kepware OPC servers will show as single OPC server to Osisoft PI. The only thing that made me angry was that after some trial time it stopped without warning all servers (including licenced ones) when I was evaluating one new OPC server I was supposed to try out. Have you tried Kepware technical support? Have you checked your cabling? Are you aware that trial version will stop after some time?
As an alternative you can try Matrikon OPC servers. They are also very good and run without problems.