Protocol architecture for communication between embedded device and remote server

2
votes

I have few questions about the best protocol architecture for a specific application. Let me explain better my application.

In my application, there are 3 elements:

  • Meter
  • Concentrator
  • Server

The meter (an embedded device) sends messages, periodically, to the concentrator (another embedded device) through a RF link. In this communication we are using the WM-Bus protocol and I don't have any problem.

The concentrator communicates, every day, with the server to transfer data collected from the meters during the day. This data can be different kind of data, such as, readout data, alarms etc. and it's possible one day the concentrator has just the readout data to be transferred and, in another day, a lot of different kind of data. In addition to this situation, sometimes, the server needs to send data to the concentrator, for example, when the server wants to change concentrator's configuration. This connection will be handled by GPRS module which has the TCP/IP implemented, therewith, low-level protocol is not a problem. The protocol which will be used in this part of the system will be a proprietary protocol and we are having problem to specify it.

We thought two possible architecture for this protocol. The first option, the server is the master (server) of the communication and the concentrator is the slave (client). In other words, the server opens a listening socket and wait for the concentrator's connection. When the concentrator opens a socket with the server, it sends its status word (bit field) which, each bit, indicates the reason of the connection, then the server starts to ask the data through specific commands.

In the second option the concentrator is the master. In this way, it opens a socket with the server and sends the data using specific commands. In my option, this option sounds better, because the concentrator knows which kind of data it needs to send and do it, instead of the first option where the server needs, first, to see the status word to decide which data it has to ask. In this architecture, although the concentrator is the master, it's still a client in the client/server model, because it's the server which opens a listening socked.

My doubt is which is better, the server behaving like a system that obey the concentrator or vice versa.

The concentrator is a ARM Cortex-M3 microcontroller and will be programmed in C language. The server will be in Java.

The architecture should be robust, because one server can be connected with 10K of concentrator and each concentrator can be connected with about 200 meters. So, indirectly, the server will receive data from 2 millions of meters.

Which architecture is more indicated for my application? Why?

1
carchitectureembeddedprotocolsgprs
It seems in both of your scenarios the concentrator is opening a socket to the server. Will the server be able to handle the situation where all 10K (or just many) concentrators try to connect simultaneously? If the server address changes will you have to go out in the field and update 10K concentrators? My first thought would be that the server should be opening the connection to each of the concentrators. – kkrambo

1 Answers

1
votes

I dont know if this going to help you but, some tracks :

  • Think about where you want to put the "intelligence". It's probably more simple to maintain one server stack compare to 10.000 concentrator stack.

  • Think about which low level protocol you are going to use TCP or UDP. This may allow you to think about the main stack automaton design.

  • You speak in terms of master/slave, but think in terms of client/server, which side open a listening socket and which side connect to the listening socket. This may allow you to precise you stack automaton design. (UDP, TCP, Session TCP, etc...)

  • Your Cortex M3 concentrator probably use an internal or external MAC interface/chip to allow TCP/UDP networking. This interface may have limitation, probably could not handle several listening ports, etc... In this case it's probably more simple to view you concentrator as client and server, as server.

Try to keep your stack as simple as possible, a simple stack automaton can be :

Server :

 1 - Open a listen socket
 2 - Accept connexion and fork or create thread
 3 - Send handshake frame (server name, version, etc...)
 4 - Wait for hello frame (client name, version, etc...)
 5 - Send GetData frame
 6 - Wait for Data frame
 7 - Send Ack frame
 8 - Send GetAlarm frame
 9 - Wait for Alarm frame
10 - Send Ack frame
11 - Send Bye frame
12 - Close socket

Each 'Wait' is protected by timeout, this close connection if append

Client :

1 - Try to connect (3 times and pause 60s if time out)
2 - On connect wait for Handshake frame
3 - Send Hello frame
4 - Wait for frame :
  4.1 - If frame is GetData, send data frame 
  4.2 - If frame is GetAlam, send alarm frame
  4.3 - If frame is Bye, close connexion
5 - Wait for Ack frame (if not disconnect)

Each 'Wait' is protected by timeout, this close connection if append

For the frame format, you can use a simple format like

|-----------------------------------------------------------------------|
|  Head | Frame |     Size      |         Data          |     Crc16     |
|-----------------------------------------------------------------------|
|   0   |   1   |   2   |   3   |   4   |  ...  |  n-3  |  n-2  |  n-1  |
|-----------------------------------------------------------------------|


* Head is fixed to 0x81

* Frames :
  * 0x00 : <forbidden>
  * 0x01 : Handshake
  * 0x02 : Hello
  * 0x03 : GetData
  * 0x04 : Data
  * 0x05 : GetAlams
  * 0x06 : Alams       
  * 0x07 : Bye
  * 0x08 : Ack
  * 0x09 : Nack

You can see you can send handshake,hello,getdata,getalarm frame (master/slave) in the way you want to simplify the stack automaton sequences... so think about a lightweight stack automaton sequences and error recovery.

Hope this help you to design your protocol