5 Communication protocol facts you need to know | Entelec

March 18, 2019

1. Communication protocols are actually a kind of language

Communication protocols can seem very technical and complicated, something that only highly trained engineers can understand. Luckily, they’re not. Basically, a communication protocol is a language in the same way we all know languages.

Let’s take the English language as an example. Both of the speakers in the image below use the English language to communicate. In this case, the English language and its grammar rules, shape the protocol used for communicating. Speaker 1 can say to speaker 2: “How is the weather today?”. Because the sentence is made up out of the right words, in the right order, speaker 2 understands the question. He can then answer for example: “It’s sunny today”. The grammar rules and words used in the conversation, are basically the protocol of the English language.

Of course, this is only a simple way of explaining a communication protocol. But just like the English language, every communication protocol has it’s set of rules. They contain important information like the message format, syntax, synchronization, error recovery methods and security. By applying this set of rules, engineers and developers can build a communication gateway between different types of systems.

2. A communication protocol is not the same as an API

This is a topic of discussion in many online forums. It seems there are a lot of disagreements on the definition of both protocols and API’s.

First off, let’s see what Wikipedia has to say about both:

API “An Application Programming Interface (API) is a set of functions, procedures, methods or classes used by computer programs to request services from the operating system, software libraries or any other service providers running on the computer.”

Protocol “In telecommunication, a communication protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity.”

After ploughing through tons or articles and forums about the differences between API and protocols, you might start to think that they are more or less the same thing, explained with different words. This is because they are both needed in order to create communication between two or more systems, resulting in confusion.

To start off, you need to know exactly what to imagine when we talk about a communication protocol. Let’s take one of the most known building management protocols for example: BACnet. BACnet (Building Automation and Control network) was designed to automate building systems such as heating, ventilating, HVAC, lighting control, access control, and fire detection.

By following the BACnet rules it is possible for an integration software platform, to communicate with several building systems, all from one central interface. Even if all systems are produced by different vendors, connections with all these systems are still possible via BACnet, which is enormously efficient for large corporations.

Now what is the difference between a communication protocol and an API? Well, the API uses the protocol in order to extract the exact information needed to carry out certain tasks. Let’s say you are an operator in a control room. On the camera, you see that in a certain meeting room the lights are still on, while the meeting is over. The operator then turns off those lights via the integration software application. For this seemingly simple task, several actions are carried out.

For example, our developers have built an API into Sky-Walker that asks the physical lighting system to turn of the lights, after which the lighting system answers to Sky-Walker that the lights have been turned off. And the language in which they ask and respond? You guessed it, the BACnet protocol.New Paragraph

3. API’s are often part of an SDK, but what is an SDK?

A term we often come across regarding communication protocols and API’s is an SDK. An SDK stands for Software Development Kit. Look at the images below to see how an API and an SDK are related.

As you can see, the API is part of the SDK. A rule of thumb is that all SDK’s contain API’s but not all API’s are part of SDK’s. An SDK is a complete set of one or multiple API’s and additional tools like test material, a demo version, extensive documentation and so on. With an SDK, the developer is able to create all applications needed for certain tasks. It is more or less the full package when hooking up another type of system to the software. It is also a developer’s preferred package of information to have of course.

4. Protocols can be either open or proprietary

Now that you know more about what exactly communication protocols are, and how they differ from API’s and SDK’s, we’re diving deeper into the protocol sea.

Protocols come in two different kinds, they can either be open, or proprietary. Each of them has its advantages and disadvantages. The open protocols are freely available for everyone. Furthermore, they are very well documented because so many systems use them. This results in a lot of forums on issue solving. They might be easy to use, and free, but in contrast they do have more security risks because anybody can learn how these systems communicate. In the PSIM sector, security is the key strength for software, so often systems are accompagnied by a proprietary protocol.

Therefore some companies produce systems that use proprietary protocols. These protocols are very specific for a set of functionalities. As not many people use them, they are safer to use as well. On of the biggest downsides on proprietery protocols is that they often cost money. Also, the information gathered needs to remain private, often controlled by an NDA (Non Disclosure Agreement).

Some typical open protocols are Modbus, Bacnet, OpenTouch, OPC, HTTP, FTP and SIA. Some of the typical proprieteray protocols are Notifier and Flex for example.

5. Sometimes a protocol needs to be requested

When a new system needs to be connected to an interface, let’s say our Sky-Walker Open Integration Platform for example, often a protocol for that specific system needs to be requested. Below is a flowchart of a typical protocol request, and as you can see, it’s not always that easy!