MBLogic for an open world in automation
HMIServer communicates with field devices such as I/O modules or PLCs by using the communications protocol which is native to that device. This section deals with the basics of field device communications and the protocols which are supported by HMIServer.
HMIServer supports the following field device protocols:
Click on the links above to read more details about these particular protocols.
Most protocols use a client/server model. This is also sometimes referred to as master/slave. A "master" is the same thing as a "client", while a "slave" is the same thing as a "server". The master/slave terms originated in industry, while the client/server terms originated in the computer industry. The different terms arose due to historical differences as to how they were being applied, but the computer industry terms have to a large degree replaced the industrial terms as industary has adopted more off the shelf computer technology.
A client/server protocol operates as follows:
For example, when you use a web browser to view a web page on the internet, your web browser sends a "page request" to the web server. The web server decodes the request and sends back a web page as a "response". Your e-mail client program fetches your e-mail in the same way from a mail server.
"Ethernet" is the most widely used network communications media. However, Ethernet by itself is not a communications protocol. Instead, additional protocol layers are added on top of Ethernet.
An "IP address" is the network address of the device which the message is being sent to. Each device on a network must have a unique IP address. The number of possible IP addresses is very large (billions of addresses).
Layered on top of IP, there are two main additional layers - TCP and UDP. When TCP is used, the IP communications software "stack" establishes a "connection" between two points and messages are sent between these end points. When UDP is used, no "connection" is established before a message is sent.
This "connection" is not a physical connection. All it means is that the IP software "stack" (or operating system) will track where the messages are intended to go, and will automatically re-send them if they don't arrive. With UDP there is no virtual "connection", so the application program needs to do any message tracking itself.
It is sometimes said that UPD is "faster" than "TCP' because there is less message tracking overhead involved. However, IP software "stacks" are usually highly optimised and so are very fast and efficient. The details of the field device protocols themselves are usually have far more influence on speed or efficiency than thc choice of TCP or UDP.
In addition to the IP address, the "port number" is required. An Ethernet "port number" does not refer to the physical connector. A port number is an number send in the Ethernet header used by the operating system or firmware in a device to determine which program a message should be sent to. This allows multiple programs to share the same Ethernet adaptor without conflict. When a client sends a message, it sends it specifies a particular port number. When the message is recieved by the server, the operating system or firmware will look at the port number and route the message to the correct program.
When a server program starts up it will "bind to a port". That simply means that it will ask the operating system to be assigned a particular port number. Only one server may bind to the same port number at any time. If the port number is already in use by another program the new server program will not be allowed to use it, and will encounter an error. When a server program shuts down, it frees the use of the port. The operating system will then wait for a certain time-out to pass (the standard is 70 seconds) before allowing that port number to be used again.
Most protocols will have a port number which they expect applications to use. However, it is usually possible to use an alternate port number provided both the client and the server can be instructed to use it. The reasons for using a different port number are usually related to avoiding conflicts with other programs using that port (including running multiple copies of the same program on the same computer), problems with firewalls, or avoiding security problems.
Operating systems such as Linux have features which allow ports to be "remapped" such that the port actually used by the application is different from the port which it appears to be using from the outside. This can be used to operate the program on an alternate port number, while still making it appear from the outside to use the "standard" port.
TCP/IP and UDP/IP port numbers are independent of each other. This means it is possible for two different programs to use the same port number, provided that one is a TCP port while the other is a UDP port.
The actual industrial field device protocol is layered on top of TCP/IP or UDP/IP. This is the "application layer" protocol. It is this protocol layer which determines whether two devices can communicate with each other. A good analogy is is a telephone system. You may be able to connect to someone on a telephone, but unless you can both understand the same language, no real communications can take place.
Examples of field device application protocols include Modbus/TCP and SAIA Ether SBus.
Web browsers such as Firefox, Chrome, or Opera use a protocol called "HTTP" (Hyper Text Transport Protocol). This is a client/server protocol which is most commonly used to transmit web pages between web servers and web browsers. A "web server" is simply a server program which understands the HTTP protocol and can use it to send data. The data may simply be files containing web pages, or the data may be created entirely "on the fly" in response to a request, or it may be a combination of the two.
As well as web browsers, other programs can use HTTP to request data from a web server. Indeed, there are many instances where the intended recipient is not an ordinary web browser. If the data is organised in a way that it constitutes another application protocol on top of HTTP, this is known as a "web service protocol". Web service protocols are used in many applications which involve interfacing different systems together, and many of the protocols involved tend to be ad hoc and application specific.