Hi to all,
I'm new to substation automation field.

Can anybody compare and tell me the similarities between master/slave model and client/server model.

Also I want to know the advantages of client/server when compared to master/slave.

master/slave and client/server are used interchangeably in some places, is it right to use like that ?

By,
srishankar
[email protected]

 

They're simply two different terms for the same thing that have different historical origins. Master/slave came from the industrial automation field where the analogy was a master (controller) directing a gang of slaves (field I/O). Client/server came from the IT computer industry where the analogy was a restaurant waiter (server) providing dishes of food to diners (clients).

The client/server has been replacing the master/slave term in industrial automation as IT computer technology (such as Ethernet) has been increasingly adopted into industry. The result is that you see Modbus/RTU referred to as master/slave and Modbus/TCP referred to as client/server even though the protocols themselves have only minor differences.

 

Hi there,

I just wanted to add that Master=Client=Scanner and Slave=Server=Adapter. Depending on what type of fieldbus, different terms are used. For example CIP networks use the terms Scanner/Adapter, while Profibus/Profinet use Master/Slave. On some types of Fieldbuses, such as DeviceNet, it is possible to have 2 (or more)Scanners (masters) communicating and on other fieldbuses, such as Modbus, masters cannot communicate directly.

Patrick Lansdorf

 

In the case of Modbus (and other similar protocols) it's not quite correct to say that two masters cannot communicate directly. It would be better stated that Modbus does not in itself provide a means of controlling a network in a manner which would allow this.

When operating as Modbus/RTU on RS-232 or RS-485, Modbus runs on the bare wire so there is no way to decide who gets to talk when. When operating as Modbus/TCP on Ethernet however, TCP/IP handles that. In that case there is no problem having a node acting as a client and a server (master and slave) simultaneously, *provided* the system has the software installed for handling both roles. The same is true for other similar protocols.

To put this another way, a client sends a request and waits for a response, while a server waits for a request and sends a response. There is absolutely nothing to stop a piece of software from doing both things at once. The only problem you have is deciding who gets to talk when, and how to get the message where it needs to go. Ethernet with TCP/IP (or UDP/IP) handles that for you. If you are operating on bare RS-232 or RS-485 however, then you have to handle that some other way.

This ability to simultaneously perform both roles should be inherent to pretty much any basic client/server (or master/slave) protocol when operating on Ethernet with TCP/IP or UDP/IP. In most cases there isn't a market demand for this ability however, so manufacturers don't often include the software for it. It's not a limitation of the protocols themselves however.

Modbus and other similar protocols are a good example of the "layered" approach to networking. Each "layer" in the network takes care of a specific task. Modbus concentrates on what the data "means" and not (except for the unit id on serial networks) on how to get the message to where it needs to go. That means you can swap the lower layers of the network for something else with little or no change to the application level protocol itself.

On the other hand, some protocols mix the layers together and as a result are very tightly bound to a particular media, or a particular hardware layout. As a result they either can't be easily ported to newer networks (e.g. Ethernet), or different control hardware.

 

To clarify or maybe complicate things. The terms "producer and consumer" are also used in this arena.

 

> The terms "producer and consumer" are
> also used in this arena.

- TCP or network communication in the it industry.

There is one process on a node in the network that is waiting for clients that want to connect which is called server.
Socket library:
int accept(int s, struct sockaddr *addr, int *addrlen);

There may be many processes out there in the network that are going to connect which are called client.
Socket library:
int connect(int sockfd, struct sockaddr *serv_addr, int addrlen );

Now in many cases the client will start asking the server for something (request) and the server will answer (respond).
Most people mean this when they talk about client/server.

But once accept()/connect() is done to setup the network connection then you can communicate in both directions at the same time on the transport level. The underlying network and data link layers will do their handshake of course.

So there is no need for a request/respond at the transport level. The server could also continuously send something.

Now "producer and consumer" is just this type of communication. For example a PLC would send data to a PC whenever something on the inputs changes and the PC would consume these values. At the SAME time the PC could send setpoints to the PLC.

In one case the PLC would be producer and PC consumer. In the other case just the opposite.

-Traditional fieldbus communication

Master/Slave in the traditional fieldbus communication is polling by the master in a client/server fashion. Normally fieldbusses do NOT have a network layer. Routing is/should not be possible because you need to know the maximum cycle time for telegrams. Which means realtime.

PS: In our http://pvbrowser.org our clients call a connect() and our servers wait with accept(). But once the connection is ok both sides start sending at the SAME time. The "pvserver" tells the "pvbrowser" what to draw on screen and the "pvbrowser clients" sends the events from the user (button clicked ...).

 

>The terms "producer and consumer"

Additionally:

Think of ping time.
The time needed for a message to go from client to server + the time needed for the response to go back from the server to the client.

Now imagine the server would be a mars robot.
And the client would be a computer in Housten Texas.

What about ping time ???

"producer and consumer" is better in that case.
Both are sending continuously.

PS: The closed loops must run on mars locally of course

 

Thanks to all for contributing to this thread.

Could someone specify at what situations an IED (Numerical relay) communicated using IEC 61850 protocol will act as client to communicate with data concentrator ?

Normally an IED will act as server only, whether it will act as client anytime ?

By,
srishankar
[email protected]

 

Master-Slave refers to a mechanism by which a communicating entity gains access to a communication medium to communicate with its peer. In a master-slave system the master is in control of access and tells the slave when it is acceptable to transmit its data. An example of this is the underlying RS-485 access mechanisms of DNP3.

Peer-to-Peer refers to a network access mechanism that enables any communicating entity to establish communications with a peer entity independently. Ethernet is an example of a peer to peer mechanism.

Client-server defines a role that is assumed by a communicating entity when communicating with its peer after access to the communications medium has been granted. Generally, and there are exceptions, a server is the entity that owns data while a client is the entity that uses/consumes the data. Servers can also send data unsolicited to a client so it is not always necessary for clients to ask for data. Client server is a one to one relationship. Because it is a role assumed by the entities on a communications channel it is not uncommon for both communicating entities to assume both roles simultaneously over that channel. The ACSI services that run over TCP/IP of IEC 61850 is an example of a client-server protocol running over a peer-to-peer system.

The TCP/IP profile of DNP3 is an example of a master slave protocol running over a peer-to-peer network.

Other roles are multi-cast, pub/sub, broadcast, etc. IEC 61850 GOOSE is an example of a multi-cast protocol running over a peer-to-peer network. Multicast is a one-to-many relationship. Broadcast is a one-to-all relationship. Pub/sub is sometimes confused with multicast because it is also one-to-many but typically involves some kind of subscription process while multi-cast does not.

A good networking text book should have more formalized definitions of these terms.

 

I agree with Ralph Mackiewicz that there is a slight difference between client/server and master/slave. They are not exactly the same

In master/slave there is just one master. For example Modbus/RTU

In client/server there can be many clients. For example Modbus/TCP

Cheers,
Jonas

 

The problem with all this hair splitting over whether Modbus is master/slave or if its client/server is that protocols like Modbus (as we're not talking only of Modbus here) are not network control protocols, they're application protocols.

To give you an example, consider the statement "Modbus/RTU is master/slave". What happens though if I tunnel it over Ethernet (as some people do)? Not a single bit in the Modbus/RTU message has changed but now I can have multiple simultaneous masters. So, is Modbus/RTU master/slave or client/server? What happens if I send a bare Modbus/TCP message over a serial cable instead of Ethernet? Now I can have only a single master. So is Modbus/TCP client/server or master/slave?

So far as protocols like Modbus are concerned there is no difference between master/slave and client/server. To do any hair splitting along those lines you would have to talk about routing protocols, which Modbus doesn't deal with (except for the unit ID).

A master sends a request, and gets a response. A client sends a request, and gets a response. A slave waits for a request, and sends a response. A server waits for a request, and sends a response. It's the same in both cases.

If you want to split hairs, then you might talk about whether a particular implementation of a protocol provides message routing and collision detection or prevention when run on particular hardware in a specific configuration, but that doesn't lend itself to nice simple labels.

 

The differences between master/slave, peer-to-peer, and client/server are important differences that define and constrain what can be done with the system involved.

For 2 masters to communicate with each other you need for each node to implement both master and slave functions so that each master function in a given node has a slave function in its communicating peer with which to communicate. If you run this configuration over a data link for which only one master can be supported (like many RS-485 multi-drop systems that do not support multi-master arbitration) it won't work. If you run this over a peer-to-peer network like TCP/IP then you can implement this scheme. The peer-to-peer network masks the master/slave limitation. That is how DNP3 works over TCP/IP, the profile for which includes the data link access master/slave functions from the multi-drop RS-485 version. DNP3 over TCP/IP looks like client/server (as long as you squint a little -- e.g. don't look at the individual packets ;-) ).

What people commonly refer to as Modbus is only an application protocol and does not include link access arbitration functions. It is client/server. It was originally designed for point-to-point RS-232 links where there was only one master and one slave. There are profiles of Modbus that run over multi-drop RS-485 links that include link arbitration based on a master/slave relationship (I think that was called Modbus Plus). When you run Modbus on TCP/IP it is client/server over a peer-to-peer network.

 

Sir

I am looking for, whether IEC 61850 standard works on TCP/IP. Is there any similarity between them?

Are the operation rules of IEC 61850 based on TCP/IP?