I'm new to OPCUA protocol, and I want to make OPCUA server on device that samples continious analog signal. What is the best OPCUA arhitecture for fast continious sample transfer to client?
I recommend
OPC UA Pub/Sub architecture : OPC 10000-14: OPC Unified
Architecture
Meaning OPC UA over MQTT.
Reason:
From a data speed perspective
END-TO-END encryption
OPC UA object encoding
standards-based data connectivity
Ref: opcfoundation, OPC UA Publish-Subscribe (Pub/Sub) - IoT becomes easier
Related
Can you please tell me what is the difference between the embedded opc ua and normal opc ua.
Actually i have search over internet but dint able to find the exact difference
if anyone knows???
If you approach from OPC UA Profiles point of view, then look at this web site: OPC UA Profiles
It contains what exactly should support Embedded UA Server vs Standard UA Server.
Embedded OPC UA server runs in a device such as a PLC (Programmable Logic Controller), smart sensor, IoT gadget or so.
"Normal" OPC UA server runs on a PC or comparable general-purpose computer.
It all depends on what profiles a server is required to implement. Most likely, an embedded OPC UA Server will support less of the specified functionality. (site quoted by #ravil has moved: OPC foundation profiles)
Some characteristic differences: supported security policies, required amount of supported parallel sessions, continuation points per session, ... So mostly stuff that relates to the limited resources typical for an embedded environment.
I am working on a project where I am trying to use cellular data services on the 3G WCDMA network in order to send data to a SQL Server database. On the client side, I am using a SIM5215E chip to connect the cellular network. This chip is being controlled by sending AT commands over a UART connection from a PIC32MX675F512H microcontroller. I was wondering, is there a relatively simple way to have this data be accepted by a SQL Server database? I have found many services and references online for sending SMS to a SQL Server database using a SMS gateway but I haven't been able to find anything for cellular data to the database.
I'm testing Audio/Video P2P connection between mobile devices.
Studying WebRTC, I've noticed NAT traversal(uses STUN server) and UDP-hole-punching is the key to make P2P possible.
On the other hand, I've noticed HLS(HttpLiveStreaming) on iOS devices is very optimized for A/V live streaming, and widely available even with Android4.x(3.x unstable)
So, here is my question if I use HLS for mobile P2P:
a) HLS is a protocol on TCP(HTTP) not UDP, so isn't there a performance drawback?
See: TCP vs UDP on video stream
b) How about NAT traversal? Will it be easier since HLS is HTTP(port:80)?
I have read wikipedia http://en.wikipedia.org/wiki/HTTP_Live_Streaming
Since its requests use only standard HTTP transactions, HTTP Live
Streaming is capable of traversing any firewall or proxy server that
lets through standard HTTP traffic, unlike UDP-based protocols such as
RTP. This also allows content to be delivered over widely available
CDNs.
c) How about android device compatibility? Is there a lot of problems to invoke StreamingLive distribution?
Thanks.
The reason why firewalls are not an issue for HLS is that it's a client-server protocol where all requests are done via HTTP on port 80. If you are implementing a P2P application, you won't be able to attach it to a port below 1024 unless you have root privileges.
This means that exchanging data via HLS (port 80) won't work for P2P. Unless you have a translation server in the middle, which defeats the purpose of P2P.
Comparing HTTP Live Streaming to P2P video streaming over UDP/RTP is almost like comparing apples and oranges. More like oranges and tangerines... read on.
HTTP Live Streaming was designed as client-server protocol without P2P or NAT traversal consideration. The idea being that the streaming server is already over HTTP/TCP and accessible from the public internet as if it was just an ordinary web server. The key features of HLS is its ability to dynamically switch the bitrate based on how well the client receives the stream. If the client connection to the server hiccups trying to stream down a 1080p video, it can transparently switch to sending a lower bitrate video (and likely switch back to streaming at higher bitrate if network conditions improve). Good example: Netflix.
WebRTC and ICE were designed to stream real time video bidirectionally between devices that might both behind NATs. As such, traversing a NAT through UDP is much easier than TCP. UDP lends itself to real-time (less latency) than TCP. Most video-chat clients (ala Skype) have dynamic bandwidth adjustments built in to their codecs and protocols to achieve something similar to what HLS does.
I suppose you could combine TCP NAT traveral and HLS together. Doing HLS over UDP implies that you build a TCP like reliability layer on top of your UDP stream.
Hope this helps
http://www.garymcgath.com/streamingprotocols.html
HTTP Live Streaming
The new trend in streaming is the use of HTTP with protocols that
support adaptive bitrates. This is theoretically a bad fit, as HTTP
with TCP/IP is designed for reliable delivery rather than keeping up a
steady flow, but with the prevalence of high-speed connections these
days it doesn't matter so much. Apple's entry is HTTP Live Streaming,
aka HLS or Cupertino streaming. It was developed by Apple for iOS and
isn't widely supported outside of Apple's products. Long Tail Video
provides a testing page to determine whether a browser supports HLS.
Its specification is available as an Internet Draft. The draft
contains proprietary material, and publishing derivative works is
prohibited.
The only playlist format allowed is M3U Extended (.m3u or .m3u8), but the format of the streams is restricted only by the implementation.
I could achieve P2P on top of HLS using WebRTC on a Android with a Mozilla Firefox browser and two others desktop browsers (Chrome and Firefox) on the same swarm.
Here's a screenshot of a presentation that I've made on the University: https://www.dropbox.com/s/zyfgs4o8al9ovd0/Screenshot%202014-07-17%2019.58.15.png
This screenshot was made by acessing http://bem.tv/demo.html.
If you want to know more about, this is my masters project and I'm publishing my advances on http://bem.tv and http://github.com/bemtv.
i would like to learn how I can make my agents communicate with a PLC(siemens S7 1200). Basically the agents are created in JADE and make a decision kind of a true and false decision which they are to send the PLC. If its true the PLC is activated or otherwise. I have heard of the concept of using simple object access protocol, but not familiar with it (if anyone knows how to use that they can help me with a sample program or means of linking my programs). To complete this by 08 April 2013
I think you're talking about OPC.
OPC is an 'open' standard guarded and maintained by the OPC Foundation.
Every manufacturer of PLCs has an OPC server that communicates over their own protocol to their PLCs. The OPC clients can be donwloaded, purchased or created.
In short [S7-1200] cable S7 over ethernet cable [PC OPC Server intern OPC Protocol intern OPC Client]
In your case, you need an OPC Server from Siemens for the S7-1200. And the OPC client will be your agent. JADE needs to have a OPC library in order to communicate over OPC. See the website of www.opcfoundation.org for the possibilities.
Now you can read and write directly into the PLC.
But, you're using an S7-1200. The new micro automation PLC from Siemens. This has a new memory lay-out and OPC need some tricks to make it work. (Has to do with direct addressing in the older S7 PLCs and the named values in the S7-1200). The following FAQ from Siemens will help you further
How do you connect a PC station to an S7-1200 with OPC?
http://support.automation.siemens.com/WW/view/en/39960679
Or you could try sending the values via TCP/IP. This requires a reprogramming of the PLC.
CPU CPU Communication
http://support.automation.siemens.com/WW/view/en/20982954
I know this is a bit late but libnodave is a package for communication with Siemens PLC's. It works in Java too which is a great plus. I don't think it is suitable for industrial applications though. I do remember Siemens having their own version of the library. Just google it.
Is there any way with vb.net of accomblishing MMS audio streaming?
Also, i read somewhere else within SO, that MMS streaming is no more supported by Microsoft. Is that true? Just curious..
Here's what I dug from Googling. Wikipedia:Microsoft Media Server says:
Microsoft Media Server (MMS) is the
name of Microsoft's proprietary
network streaming protocol used to
transfer unicast data in Windows Media
Services (previously called NetShow
Services). MMS can be transported via
UDP or TCP. The MMS default port is
UDP/TCP 1755.
Microsoft deprecated MMS in favor of
RTSP (TCP/UDP port 554) in 2003 with
the release of the Windows Media
Services 9 Series, but continued to
support the MMS for some time in the
interest of backwards compatibility.
Support for the protocol was finally
dropped in Windows Media Services
2008.
The spec for Microsoft Media Server (MMS) Protocol is public since 2008 by Microsoft:
The client can send MMS Protocol
request messages to the server over
the TCP connection, requesting the
server to perform actions such as
starting and stopping the flow of
multimedia data. The multimedia data
is transferred either over the same
TCP connection or as a flow of UDP
packets.
w:VLC media player apparently supports MMS streaming, and also has API binding to various languages, including C#.
w:Real Time Streaming Protocol lists some server implementations that supports Real Time Streaming Protocol.