For most modern software applications, the developer doesn’t have to think much about hardware integration. Many hardware components the software comes in contact with—displays, pointing devices, keyboards, cameras, mobile device GPS receivers, etc.—have application programming interfaces (APIs) or are represented by standard interfaces built into the operating system.
Things get more complicated when custom hardware is involved. The prototyping, development, and testing effort can be much more extensive and complex than those of a garden-variety mobile, web, or PC application. This type of project requires additional expertise and skillsets most in-house development teams don’t possess.
For many product owners, this is uncharted territory. Unfortunately (or fortunately, depending on your perspective), the expected growth in applications dependent on internet-of-things (IoT) devices is driving a large increase in the number of these projects. Knowing what to expect when navigating these unfamiliar waters will go a long way towards preventing unpleasant surprises.
In this article, we describe some of the IoT application development tasks you might not think of if you’ve never been through the process.
First Steps: What Problem Are You Trying to Solve?
As with any development project, an IoT application project starts by defining the business problem you need to solve. Just as important is defining what problems you aren’t going to solve in this project.
It’s tempting to include multiple related or similar problems in a development project but given the higher complexity level of a typical IoT application project, this kind of scope creep can have disastrous effects on the timeline and budget. Draw clear boundaries around the problem and keep the scope within those boundaries.
With a well-defined scope, you can start documenting the system’s functional requirements: What is the system supposed to do? In particular, what is the IoT device going to do? For example:
- Will it detect physical attributes, such as temperature, pressure, humidity, radiation, or concentration of a certain chemical?
- Will it identify conditions based on images (either still photos or video), sounds, or vibrations?
- Will it take physical action, such as opening or closing valves or dampers, or moving objects?
…and so on. Important additional questions to ask about the IoT devices include:
- How will they be powered (battery, solar cell, “wall wart,” power over ethernet…)?
- How will they communicate (ethernet, wifi, or some other wired or wireless protocol)?
- In what type of physical environment will they be deployed (indoors, outdoors, office, factory, warehouse, harsh chemical environment…)?
Hardware: Build or Buy?
Once you have the hardware requirements specified, it’s time to determine if there are existing devices on the market meeting those specifications, or if you need to have your devices custom-built.
You may find commercial devices that meet your exact needs, but it’s more probable you will find devices that almost meet your requirements or that what you need doesn’t exist. The manufacturer might work with you to modify their design for devices that don’t quite match your specifications. Or you could revisit your requirements, trading off among your requirements, available devices, and cost.
When evaluating off-the-shelf devices, some important considerations include:
- Do they require calibration? How is calibration performed, and how often is it needed? For devices that will be deployed in difficult or dangerous to access locations, frequent hands-on calibration requirements can add significant operational costs.
- How easy is it to update the firmware or other embedded software? Can firmware updates be performed remotely?
- What is the manufacturer’s technical support model for the device?
- What security measures are designed into the device?
That last point is critical.
Ubiquitous IoT devices mean abundant pathways for potential hackers to access your network and data. Devices without security baked into the design are going to cause trouble.
If there’s nothing on the market that will suit your needs, be prepared for a longer development and testing cycle. The manufacturer you work with will need specific, detailed functional, physical, security, and performance specifications. The device will need firmware developed and may need a custom API as well to make life easier for the application developers.
The hardware will need to be tested, preferably under conditions that match the real-world environment in which they will be deployed. The tests should show whether the devices meet your specifications and if their performance is consistent over time and from one device to another.
App Development and Testing
On the application software side, development can be done in parallel with the hardware, to a certain extent. Full, real-world integration testing with the hardware can’t be done until the hardware is available for testing, so any data input from the devices might need to be simulated during much of the software development cycle.
Some potential pitfalls to avoid include:
- The hardware and software teams cannot work in isolation from each other. The format and content of the data exchanged between the software and devices should be established and finalized before any development work begins, and any required deviations must be carefully coordinated and their full impacts explored. A robust change control process is essential here.
- The data used in simulations should be representative of as many operational conditions as possible. Testing with the same narrow simulated conditions is a recipe for a system that works only part of the time.
In addition, security is just as important on the application side as it is on the hardware side. For high-risk deployments, consider enlisting the services of a security consultant who can try to “break” the system and make specific security-related recommendations.
Launch Considerations
When you’re satisfied the system has passed a rigorous, real-life testing regimen and solves the original business problem, it’s time to launch. How this is done depends on whether it’s intended for internal deployment or for sale to outside customers.
For internal deployment:
- Have the endusers been trained on the proper use of the system?
- Is the network infrastructure ready? Will the wired or wireless network handle the additional load?
- Is the server environment (whether cloud or on-premises) ready? Can all the incoming data be stored in a safe, reliable manner? Is the data storage capacity sufficient for the expected incoming data?
For external customers:
- Have your order desk and technical support teams been trained to help customers with the system?
- How is the hardware being distributed? Will customers have the choice to buy devices from any supplier? Does your system work with only one make and model? For custom devices, is there sufficient stock to meet expected customer orders?
- How will the app be distributed?
- What is the manufacturer’s lead time requirement for fulfilling orders for more hardware devices?
- What is your technical support model for the system?
As you can see, the IoT app development process is quite a bit more involved than a run-of-the-mill software project. But careful planning, coordination, communication, and getting the right people involved in the project from the start can chart a smooth path to success.
