5 Communication protocol facts you need to know | Entelec

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

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.

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.

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!