====== IoT Design Methodologies ======
IoT systems are software-intensive smart cyber-physical systems (CPS) and include components from three main domains: the hardware, mostly electromechanical devices; software, mostly microcontroller-specific process control software; and communication infrastructure. To develop an IoT solution, all aspects of these three domains must be designed in great synergy. When looking at the component level, the main building block of the IoT system is a node. The node is usually a microcontroller-powered device dedicated to performing a specific task. The most common task is to perform measurements from the environment, but the node can also act as an actuator or user interface. In addition, IoT nodes can provide all kinds of supportive functions, like logging, providing time, storage, etc. However, the main function is still connected to the three main functions of sensing the environment, actuating or interfacing with humans, i.e. user interfaces.
Today, CPS are created by expanding mechatronic systems with additional inputs and outputs and coupling them to the IoT. In principle, the IoT system is similar to classical smart systems, e.g., robots or mechatronic systems. These systems can be decomposed into three interconnected domains: process control by software, mechanical movements, and sensing of physical parameters from the system's environment. The figure below demonstrates how these domains are interconnected to act as a smart system.
{{:en:iot-reloaded:fig1._smart_system.png?200|}}
Smart system components and interactions
The IoT system has a similar purpose as general smart systems. Still, the main difference is that the IoT system is a distributed solution of smart functions using internet infrastructure. Similar functionality is decomposed into smaller devices acting as a single functioning device rather than a complex system. Nevertheless, when all small nodes are interconnected and can exchange messages with each other despite their location, we get a powerful system dedicated to performing automation tasks in very wide application domains. The following figure represents the IoT system architecture, its distributed nature, and its communication function.
{{ :en:iot-reloaded:fig2._iot_system.svg?800|}}
Smart IoT system components and interactions
Even if the IoT system has a different component architecture from a regular mechatronic system, the development methodologies can be easily adapted from mechatronic system design and software system design domains. IoT system has its own specifics but at the conceptual level it is as any other smart software-intensive system. Thus, the methodologies are not IoT-specific but combinations and adaptions from related domains.
===== Product development process =====
The product development process is a well-established domain, and many different concepts exist. Over time, as the software part is increasing in today's technical systems, more and more software development methodologies are integrated into the physical product development process. IoT systems are similar in their component level to cyber-physical systems consisting of characteristics and features of mechatronic, software and network systems. Thus, the existing product design methodologies are also logical choices to apply to the IoT system design process. The general product design process, despite the product's nature, has several iteration steps through the design stages.
The classical product design process starts with requirement analysis followed by conceptual design. When the design candidate is selected, the detail design stage develops domain-specific solutions like mechanical, electrical, software, etc. The next stage is to integrate domain-specific design results into one product and validate the solution. In addition, the product design process must deal with manufacturing preparation, maintenance and utilization planning. In the figure below, the general process is illustrated for most of the technical systems designs despite the application fields. However, depending on the system specifics, several other relevant stages and procedures might be important to pass.
{{:en:iot-reloaded:fig.3_product_design.png|}}
General product design stages
===== V-model =====
IoT systems are a combination of mechatronic and distributed software systems. Therefore, design methodologies from these domains are most relevant for IoT systems. For example, the well-known V-model has long been used for the software development process but has also adapted to the mechatronic design process. The Association of German Engineers has issued the guideline VDI 2206 - Design methodology for mechatronic systems (Entwicklungsmethodik für mechatronische Systeme) ((VDI/VDE 2206 "Entwicklung mechatronischer und cyber-physischer Systeme"
)). This guideline adopts the V-model as a macro-cycle process. The V-model is in line with general product design stages but emphasises the verification and validation through the whole development process. The execution of processes happens in a sequential manner similar to V-shape, thus the name. The actual design process runs through a number of V-shape macro-cycles. Every cycle increases the product maturity. For example, the output of the first iteration can be just an early concept-proof prototype where the last iteration output is ready to deploy the system. How many iterations are needed depends on the complexity of the final product. In the figure below, the IoT system design adapted V-model is presented. The only difference from mechatronic systems is a domain-specific design stage. However, every general stage has several internal procedures and IoT-specific sub-design stages which must be addressed.
{{:en:iot-reloaded:fig4._v-model.svg?400|}}
V-model for IoT systems
The new product development starts with customer input or other motivation, e.g., a business case, which must be carefully analysed and specified in a structured way. Requirements are not always clearly defined, and to put effort into proper requirement engineering pays off to save significantly from later design stages. It is not good practice to start designing a new system or solution when requirements are not adequately defined. At the same time, rarely all information is available initially, and requirements may be refined or even changed during the design process. Nevertheless, well-defined and analyzed requirement specifications simplify the later design process and reduce the risk of expensive change handling at later stages. The initial requirements are articulated from the stakeholder's perspective, focusing on their needs and desires rather than the system itself. In the subsequent step, these requirements are translated into a system-oriented perspective. The resulting specification from the requirements elicitation process provides a detailed description of the system to be developed,
The second design stage is a system architecture and design dedicated to developing concepts for the whole system. Concept development and evaluation are decomposed into several sub-steps and procedures. For example, different concept candidates' development, assessment of concept candidates, and selecting the best concept solution for further development. Once the concept solution is selected and validated with requirements, the final solution candidates can be frozen, and the development will enter the detailed design stage. In the detailed design stage, domain-specific development occurs, including hardware, software, network structure, etc. Once the domain-specific solutions are ready at the specified maturity, integration and validation will follow. The final step before the first prototype solution is full system testing and again verifying and validating according to the system requirements.
The whole process may be repeated as many times as necessary, depending on the final system's maturity level. If only proof of concept is needed, one iteration might be enough—often the case for educational projects. But for real customer systems, many V-cycles iterations are usually performed. Once the design process is completed, the system enters the production stage, and then the focus goes to system/user support and maintenance. However, like in modern software-intensive systems, constant development, bug fixes, upgrades, and new feature development is common practice.
===== Challenges =====
When designing an IoT system, there are common design challenges as in any other system engineering project, but also a few IoT-specific aspects. The engineering team must deal with challenges similar to mechatronic and software system design challenges. Some relevant key aspects to address when designing and deploying a new IoT system:
* New IoT system often requires organizational and working culture changes, which are often underestimated. Changing workers' mindsets to collaborate with new IoT systems might be a critical issue and often underestimated during the design process.
* Due to the complex nature and dependence on several existing systems, IoT projects tend to take much longer to implement than anticipated.
* IoT systems are multi-domain solutions and thus require engineering skills from very different fields, which might not be available. Naming some of them like microcontroller programming, sensors, data communication, cybersecurity, etc.
* Interconnectivity issues can be critical as the IoT system components must be able to communicate with each other, but there are tons of protocols, network architectures, and even electrical connectors that may fail.
* Data security is often underestimated. IoT system is not a standalone system but, in most cases, interconnected systems through the public internet. This means that implementing cybersecurity is very challenging because the overall system security is defined by its weakest segment.
* Scalability and dealing with legacy equipment. IoT systems often update old heavy machinery in the industry and combine old and new technologies. This might be more challenging than expected and, in some cases, extremely costly to eliminate all interfacing issues.