Intersog's CEO Igor Fedulov and senior Android developer Igor Rolinskiy are going to speak at the upcoming IoT Conf UA, one of Ukraine's largest IoT events that will take place in Kyiv on February 27, 2016. The topic of their presentation is Peculiarities of the IoT application development, how it differs from traditional software development projects and the most in-demand IoT project requests Intersog receives from our Western prospects.
In anticipation of the presentation I've talked to Igor Rolinskiy to learn more about the uniqueness of IoT solutions development and pitfalls of distributed IoT development. Below is a brief summary of key talking points of the Intersog presentation for the Conference.
Main difference between IoT and typical software development projects
When it comes to IoT applications, we, software developers, have to deal with a higher number of interacting devices: in traditional software projects we deal with client-server communication, while in case of IoT we should handle client-client-server communication. In addition, IoT development envisions a big variety of technologies and programming languages including embedded development, modular platforms, mobile devices, IoT dev platforms and more.
Main complexities of building applications for IoT devices
- Specific interaction protocols such as constrained application protocol (CoAP)
- A very limited number of libraries for m2m interaction implementation
- Lack of m2m interaction standards, which results in multiple types of implementation based on either web standards or company specific standards
- Difficulties of connecting devices through Bluetooth: e.g., simultaneous connection issues attributed to hardware limitations
Pitfalls of IoT application development in a distributed environment
In cases when mobile application is built in one country and IoT device is built in another country (e.g. outsourcing engagement), issues with application testing and troubleshooting usually arise. To solve them, we deploy excessive logging in the source code in order to be able to detect both developer mistakes and errors in device firmware.
For testing and debugging we normally use a PC located on the same premises as the device itself. The PC has all of the required troubleshooting tools installed and is remotely connected to our R&D Center in Ukraine. Webcam able to demonstrate the IoT device being tested offshore is a must, as real-time performance of the device can tell us more than the logs. Because communication between devices occurs in the automated mode and Internet connection can often be unreliable, we need to create interaction algorithms that are resistant to disconnection. They should allow for autonomous reconnection and work continuation from the point of connection failure.
Auxiliary tools used for IoT application development
Because development of different system components is distributed across 2 or more locations, we use device emulators. Emulator isn't a device, it's a simulation software program that's launched on PC and uses PC communication, which puts certain restraints on development and increases the risk of error. But we have our own secrets to prevent errors when using IoT emulators.