I am new to OPC UA standard and being a java developer was trying to search for a good java library for the standard.
I cam across https://github.com/OPCFoundation/UA-Java and Eclipse Milo(or digitalpetri).
How does Eclipse Milo compare with UA-Java? which one should I choose?
My use case is to develop a NIFI(nifi.apache.org) custom processor that can read data from an OPC UA server like Kepware and channel that data into our bigdata store and later build analytics on top of it. I want to implement OPC features like subscription and historical data access as well in the processor.
I may be a little biased as I'm the primary author of Eclipse Milo, but you should use it because it's both a stack and SDK implementation of OPC UA where the code provided by the foundation is only a stack.
If you don't have extensive knowledge of OPC UA and time to write a lot of code that SDKs have typically already written then you don't want just a stack.
You might find these links on the subject helpful to your effort
https://community.hortonworks.com/articles/90355/collect-data-from-opc-ua-protocol.html
https://community.hortonworks.com/articles/88649/control-system-data-from-kepware.html
Related
I'm working on IoT project where I receive datastream in CoAP protocol.
I want to process the data in Heron by doing some transformations on top of it.
Is it possible to integrate CoAP protocol objects to heron?
I think it is not very important from the CoAP endpoint's view where do you put the received data.
Use this link as a initial point:
http://coap.technology/impls.html
There you can find brief descriptions for implementations for several languages/platforms.
Unfortunately, I am not familiar with Twitter Heron and don't know which language is best for implementing a Heron data provider.
If such language is Java or Heron is language-agnostic (say, has a REST API as a primary interface) - I'd consider the https://eclipse.org/californium/ as a very mature implementation. That way (sure in 5000ft view as I don't know the details) you could write an app which uses Californium and CoapHandlers might push data to Heron.
We have a traditional VB application which are used for Organization operations. Now we are building a Hybrid application developed by using HTML5,CSS and Javascript which is targeted on Google Chromium desktop container. Now we are planning to provide a way to exchange large data like employees records between both of these 2 applications. Now my specific question is
What are the different ways to achieve communication between Chromium desktop container and VB application to exchange large chunks of data?
Sounds a bit painful no matter what.
Chrome Apps Architecture
All external processes are isolated from the app.
This would seem to suggest the obvious course is to use cloud data services, whether on public or private clouds.
I suspect that for political as well as practical reasons no cloud vendor goes to the trouble to provide VB/VBA-friendly APIs for their services. Mainly nobody wants to deal with support issues from the teeming hordes of casual coders the VB community is saddled with.
The VB6 community hasn't stepped up and taken care of this themselves either.
If you can limp along with the burdens of ".Net Inter Clop" (the usual MS answer) that might be a way to exploit existing API implementations.
Otherwise you might roll your own cloud. I see a few obvious services you'd want to implement in your cloud with lightweight APIs easily implemented in both of your development ecosystems:
Bulk Storage. I suggest WebDAV, which IIS supports. If you eschew the locking features then WebDAV API implementations are pretty easy in both JS and VB. Or buy (or scrounge open source) implementations of a more complete WebDAV client library.
DBMS. Pick any, implement a simple REST-like XML over HTTP API. Relatively easy to implement.
Push Notifications. I'd write a custom service accepting long-duration TCP connections from all clients, and with protocols and workflow à la Amazon SNS or Google Cloud Messaging. Such a service would be generally light in resource consumption but you'd probably want a dedicated box with OS tweaks to support a large number of active TCP connections.
Maybe optionally a message queue service?
Nothing novel here, these are all well established patterns.
All of the tools to do that are pretty off-the-shelf whether you want your cloud servers to be based on Windows, Linux, or generically Java anywhere.
Most of the effort will probably go into developing a consistent authentication model, access control model, and of course an integrated administration interface, monitoring, and logging to help keep operating overhead low and uptime high. Well, that and developer docs and training.
Ok, still a lot of work. Too bad there isn't a "cloud in the box" with the API libraries you'd need that you can buy off the shelf today.
Or perhaps I'm missing something obvious?
I have some questions about implementation of OPC :
Can I write my own OPC server and OPC client for a PLC that want to send and receive real-time data to the server ??
How much is easy for a undergraduate student ??!!
Or can I use free software for the server (for example "MartikonOPC Explorer") and for the client to connect to the PLC ??
Which Programming language can I use ?
======================================
review :
PLC model : Delta
Can I write my own OPC server and OPC client for a PLC that want to
send and receive real-time data to the server ??
yes you can, sounds as if you only need OPC DA i.e. read/write of values.
How much is easy for a undergraduate student ??!!
It depends, if you want to implement OPCDA 3.0 then you would need some knowledge about COM which could be daunting if you haven't worked with it before. Normally when you create a OPC server you would use a framework from some vendor e.g. Matrikon but if you are on a tight budget you may need to do it all yourself.
Or can I use free software for the server (for example "MartikonOPC
Explorer") and for the client to connect to the PLC ??
You can use the Matrikon OPC explorer to connect to your OPC server but normally you want to embedd your client code in a program and do something with the values, the explorer is more for testing
Which Programming language can I use ?
For the server part C/C++, for the client part you are more flexible, any language that supports COM
Alternatively you could implement an OPC UA server instead, OPC UA is platform independent and pretty much language independent.
See more at opcfoundation.org
Depending on your skills the answer can be yes or no. The OPC foundation holds the standards and these are available to members.
Keep in mind that PLC's don't use OPC for communication, an OPC server uses the PLC manufacturers propriety protocol to be able to "serve" data to clients using OPC protocol.
To properly answer this question it needs a lot of clarification, how much is easy for a undergraduate student depends on what you study.
Which programming language to use, any you can find, what's your prefference.
Python is easy way and can do.
Only create global communication module (global for reuse).
Some problems :
1- More PLC brand use BUFFER for access (Delta not use).Need register first later can read (all EV values).
2-All inside a thread (not only one, per node threading)
3-Your resolution is 1/10 sec(for modbus over serial)
4-Need write a strong security program in PLC (otherwise claim a lot risk!)
5-Minimal communication line is 2(two)(when lose one, use other).
All programming language is a baby. If you feed a lot and love it, groove up faster.You can do ! Don't forget you got a baby!
Last time I checked Delphi was the only one to have both free OPC client and OPC server examples. I have made both OPC DA 2.04 servers and clients using sources from this page.
Just curious, if you were to build an instant message client for the Mac what existing API or service would you use to handle the transfer of messages from one user to another? I am looking for something that can be used in conjunction with objective-c and is compatible with other popular messaging services such as MSN, Yahoo, Aim, gtalk, etc. I don't want to host the service, but rather connect to existing services and use their "pipes".
Thanks
There are many Instant messenger protocols out there.
There is a good bet you could find a Java API for which protocol you would like to use like the XMPP Java API.
Or
for C or C++ you could use the libpurple library.
Your question lacks a lot of informations, so it's rather hard to answer. Please add some details on your requirements. What protocols do you need, what functionality, what development language do you use?
As a start:
Adium has been released under the GPL, thus you can use the code in your own projects as long as the license fits your needs.
http://trac.adium.im/
Another option, if you don't want to implement multiple networks but prefer to use a single protocol where the server provides gateways to other networks you can also check out Jabber/XMPP libraries that are available for the mac.
http://www.google.de/search?q=jabber+library+mac&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a
So far I have seen non-Java client support only for open source message brokers like Apache ActiveMQ, JBoss HornetQ and Open Message Queue (OpenMQ).
Are there also closed-source products like WebSphere, WebLogic or Tibco which offer non-Java access to their MOM brokers, using a documented wire protocol (opposite to a closed-source binary client library) which allows to write clients in other languages?
This is getting more interesting as products (like WebLogic) are available in the (EC2) cloud so that developers can use the cloud instance to develop and test a client application without the need to purchase and install the full version.
I don't have a definitive answer because I specialize in WMQ exclusively. However, I believe the answer is "no" for the most part. (More on that in a minute.)
Regarding WMQ IBM makes available exit points to tailor the behavior of the channels, API calls and authorizations. Exits are very well documented and perform narrow functions within the scope of a particular action - i.e. receive a message, initiate a connection, etc. These are written in C and, more recently, Java. For the most part these are unused and customers I talk to generally cite complexity. They want something customizable through configuration and not through low-level code. I suspect other MOM vendors experience similar requirements from customers.
What does this have to do with your question? My take on this is that if customers are reluctant to code up exits with limited function, it seems far fetched that they would code up a full-featured and robust client that supports reliable message delivery, one- and two-phase commit, client-side exits, diagnostics, and all the other functionality that WMQ channels provide.
Assuming that this task was undertaken by an open-source team capable of that level of code, who would support it? the MOM vendors currently provide end-to-end support when using their proprietary clients. The notion of how a trouble ticket might be resolved when using a third-party client that is community-supported is a bit scary to many customer. For example, IBM supplies add-ons for WMQ called SupportPacs. Although there are SupportPacs that are fully supported and are considered product extensions, some of the SupportPacs are provided as-is. Many of my customers won't run as-is code even when it is supplied by the vendor.
Finally, there is the notion of the interface contract. WMQ supports a few verbs with a lot of options. The underlying channel protocol is MUCH more complex. When WMQ v7 came out, the channels had considerable new functionality and tuning. this was possible at this scale because the internals are not exposed to clients and so IBM was able to make massive changes without fear of negative impact to 3rd party clients. Exposing all of that would create dependencies on an order or two higher magnitude than exist with just the API's exposed.
So, according to my theory (I don't pretend to speak for the MQ development team here) the big MOM vendors have a vested interest in not exposing their channel protocols to independent developers. The new wrinkle here is AMQP which I alluded to above. It defines the wire protocol and allows each vendor to code a compliant product. Although this provides the opportunity you describe for open-source solutions, the ability of any one implementation to improve the product is limited by the fact that they don't own the protocol. For the time being though I don't expect you'll find any of the big MOM vendors exposing their wire protocols for 3rd party development. That said, this is just a guess and if I'm wrong, I'm sure someone here will jump in and provide the counter-example.