Every month, we roll out a new set of capabilities enhancing our cloud platform for IoT and Identity. This month we are discussing device event streaming and the wide range of IoT protocols supported by the Covisint Cloud Platform.
Interoperability and industry standards.
What do connected vehicles, smart cities and smart homes have in common? Sensors, connectivity and data streams. Once devices are connected to the internet and properly authenticated, they become capable of exchanging data with other smart devices or systems. Unfortunately there is no single way to collect, process and share device data today.
Some industry standards are emerging and Covisint is already supporting the most widely adopted of them to simplify integration through interoperability:
MQTT: a lightweight, publish-subscribe-based open messaging protocol on top of TCP/IP (ISO/IEC PRF 20922)
AMQP: an open standard application layer protocol for message-oriented middleware
STOMP: a simple text-based protocol, designed for working with message-oriented middleware
Other standards such as CoAP and XMPP are also gaining traction and under consideration for our upcoming releases.
One size does not fit all.
While encouraging the use of standards, we have also realized that not all devices will ever support them. Sometimes due to technical or design constraints (e.g. low power supply, low processing power), sometimes because vendors have created proprietary protocols that best fit their device capacity or the type of transactions they expect. For those, we have created a Custom Application Protocol Service (CAPS).
CAPS allows solution developers to create custom data streams per the table below. CAPS supports custom application protocols that are created on top of lower level network protocols such as UDP and HTTP. Devices can be associated to custom streams or to specific messages matching defined attributes.
|Active sending||Device-initiated||Transfer of data from device to platform||Upcoming|
|Passive sending||Platform-initiated||Transfer of data from device to platform||Released|
|Active receiving blast||Platform-initiated||Realtime transfer of data from platform to device||Released|
|Active receiving||Platform-initiated||Scheduled (batched) transfer of data from platform to device||Upcoming|
|Passive receiving||Device-initiated||Request for transfer of data from platform to device||Upcoming|
Optionally, device data streams can have payload encryption (AES, Speck, and Simon).
Figure 1 – example of “passive receiving” integration using CAPS (HTTPS)
A platform for current and future IoT needs.
In a recent implementation, we have enabled a manufacturer of industrial equipment and appliances to connect a disparate set of devices (smart lights, controllers, industrial machines) thanks to CAPS. This customer was able to use both standards-based and proprietary protocols and centrally manage these devices and their data streams in a consistent and unified way. We have also used CAPS (UDP) for integrating an OBD II dongle in two automotive use cases: one for aftermarket Connected Vehicle, another for Fleet Management.
With CAPS and its flexible integration pattern, developers can now integrate various systems without building complex and hard to maintain custom connectors. This approach saves precious time and costs in terms of implementation, enables a faster roll out for business-critical connected services, and greatly simplifies their operation and maintenance.
When building IoT integrations, it is important for developers and product managers to know that their platform for IoT solutions embraces and extends a wide range of technologies and provides longevity as protocols evolve.