A Wireless IoT Design Framework
By Tom Carpenter On 09/29/2021
A framework provides a guide for a process, system, or component of an information system. A wireless IoT design framework establishes the processes that should be included in a wireless IoT solution design effort. We present an example framework in this post.
A wireless IoT solution is not implemented in a vacuum. It must be designed based on the objectives of the organization and stakeholders and must consider elements beyond the wireless links. CWNP offers the framework shown above as a starting point for the wireless IoT design process.
The framework is comprised of four process groups, seven design processes, and a cross-cutting process for Quality Requirements. It is launched at the completion of requirements engineering or at the point when requirements engineering are sufficiently complete to begin the design process as the requirements and architecture are inputs to the framework. The groups include Network, Data, Apps, and Operations. In the Network group, the Wireless IoT Network, Wired Network, and Supporting Services are the focus. In the Data group, the IoT Data Protocols (DDS, MQTT, CoAP, HTTPS, etc.) and Data Storage and Streaming are the focus. In the Apps group, the applications are the focus including event monitoring, dashboards, analytics, reporting, AI, ML, control, and custom applications. Finally, in the Operations group, the focus is on Monitoring and Maintenance.
Each design process within a group provides the most common elements that must be considered or designed in the process. At first, it may appear that some items are missing from the lists. Consider the example of frequency. A quick glance at the framework reveals that we have not included the term frequency or the phrase frequency band in the list. However, notice that protocols and channels are in the list. Indeed, the protocols you select to use and the channels on which the network will operate determine the frequencies or frequency bands that will be implemented. It is assumed that this framework will be used by a professional who understands regulatory constraints for the target region. Therefore, regulatory agencies and regulatory control are not directly listed either.
Another example is the Hardware component in the Wireless IoT Network task. This is inclusive of end devices, gateways, FFDs, RFDs, and basically any device that is part of the wireless IoT network. Generally speaking, to design the wireless IoT network, you will start with the end devices, understanding what is required by them, and then implement the wireless IoT network design to meet these requirements. You do not typically start by choosing a wireless IoT protocol, like ISA100.11a, and then ask, "How do I make these devices work with this?" Exceptions do exist, of course, such as when an existing wireless IoT network is in place and the organization wants to add end devices to that network. The goal was to provide a framework that motivates the consideration of the important factors, which will, in turn, lead to other factors of which the professional is aware.
One final note about the framework should be made. Notice that one component is in every design task within every group: Quality Requirements. Security should be a consideration in every element of the design. Using this approach results in better security overall. Security is a cross-cutting or horizontal requirement. If you consider the wireless IoT network, wired network, supporting services, IoT Data protocols, etc., as vertical design tasks, security and other quality requirements drive horizontal design tasks. This is not unusual to a quality requirement imposed on the design. To achieve these quality requirements, they must be considered within each component of the system because the goal is end-to-end security, end-to-end QoS, end-to-end reliability, etc.
For more detailed information on the application of this framework, see the CWIDP-401 Study and Reference Guide, Chapters 6 and 7.
Tagged with: wireless IoT, wireless IoT design, network design, architecture design, design framework
Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.