- ✓IoT application planning must address the specific constraints of the target deployment environment, including power availability, network connectivity quality, physical access for maintenance and the operating conditions of the sensors and devices involved.
- ✓Defining functional and non-functional requirements for an IoT application requires engaging closely with the people who will use it and the environment in which it will operate: assumptions made in isolation frequently prove incorrect in practice.
- ✓Protocol selection is a significant architectural decision in IoT design: the wrong protocol choice can result in inadequate bandwidth, unacceptable power consumption, unreliable connectivity or prohibitive infrastructure costs.
- ✓Edge computing, which processes data locally on or near the device rather than sending everything to a central cloud, is increasingly important in IoT design for applications that require low latency, operate in environments with unreliable connectivity, or generate very high data volumes.
- ✓Security must be addressed in the design phase of an IoT application: adding security to a deployed IoT system is significantly more difficult and expensive than designing it in from the start, particularly for devices that cannot easily be updated remotely.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Hello and welcome back. Today we're looking at how to plan an IoT application before you start building it. Sam, given the complexity of IoT systems, planning seems even more critical than in conventional software development.
Sam: Much more critical. With conventional software, if you make a design decision early that turns out to be wrong, you can often refactor your way out of it, though it's expensive. With IoT, some early decisions, particularly around hardware selection, communication protocols and physical deployment architecture, are much harder to reverse once devices have been physically installed. The cost of getting it wrong in an industrial IoT deployment where you have to physically access thousands of sensors can be enormous.
Alex: What are the key requirements that need to be established in the planning phase?
Sam: I'd group them into four categories. Functional requirements: what must the system actually do? What events should it detect? What actions should it trigger? What information should it provide and to whom? Non-functional requirements: how reliable must it be, what latency is acceptable between an event and a response, what data volumes must it handle, what uptime is required? Constraint requirements: what power is available at the device locations, what network connectivity exists or can be installed, are there physical environmental factors like temperature, moisture or vibration that affect hardware selection? And cost requirements: what is the budget for hardware, connectivity, cloud services and ongoing maintenance?
Alex: Protocol selection seems to be a particularly consequential decision.
Sam: It is. The protocol determines how devices communicate, and it affects range, bandwidth, power consumption, network infrastructure cost and device cost. WiFi provides high bandwidth but consumes significant power and requires a router nearby. Bluetooth and Zigbee are low-power but have short range. LoRaWAN provides long range and very low power consumption but limited bandwidth, making it ideal for sensors that only need to transmit small amounts of data infrequently. Cellular, including NB-IoT and LTE-M, provides excellent range and coverage but has higher power consumption and connectivity costs. The right protocol depends entirely on the specific application requirements.
Alex: What about edge versus cloud processing in the design?
Sam: The design question is: for each type of processing, where does it make most sense to perform it? Time-critical actions that need to happen within milliseconds should happen at the edge because cloud round-trips add too much latency. Data that has privacy implications may need to be processed and anonymised at the edge before being transmitted. High-volume raw data that can be summarised should be summarised at the edge to reduce transmission costs. Strategic analytics and machine learning training that uses historical data makes more sense in the cloud where compute is elastic and storage is cheap.
Alex: And security needs to be in the design from day one?
Sam: Absolutely. Device authentication: how does the system know that data is coming from a legitimate device? Data encryption: is data encrypted in transit and at rest? Secure update mechanisms: how will firmware updates be delivered securely throughout the device's lifetime? Physical security: how are devices protected from physical tampering? These questions need answers in the design phase, not after deployment.
Alex: Thorough and practical. Thanks, Sam. We'll look at the actual development process next.