====== IoT Design Methodologies ======


IoT systems are networked cyber-physical systems (CPS) and include components from three main domains: the hardware, primarily 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-based 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 is 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 ({{ref>smartsystem}}) demonstrates how these domains are interconnected to act as a smart system.


<figure smartsystem>
{{ :en:iot-reloaded:smart_system.svg?200 |Smart System Components and Interactions}}
<caption>Smart System Components and Interactions</caption>
</figure>


The IoT system has a similar purpose to 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 vast application domains. The following figure represents the IoT system architecture, distributed nature, and communication function.

<figure smartiotsystem>
{{ :en:iot-reloaded:iot_system.svg?800 |Smart IoT System Components and Interactions}}
<caption>Smart IoT System Components and Interactions</caption>
</figure>

Even if the IoT system has a different component architecture from a regular mechatronic system, the development methodologies can be easily adapted from the domains of mechatronic systems and software system design. IoT systems have their specifics, but at the conceptual level, they are like 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 with many different concepts. 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. Despite the product's nature, the general product design process 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 integrating domain-specific design results into one product and validating the solution. In addition, the product design process must deal with manufacturing preparation, maintenance and utilisation planning. The figure {{ref>productdesign}} illustrates the general process for most technical system designs, regardless of the application fields. However, depending on the system specifics, several other relevant stages and procedures might be essential to pass. 

<figure productdesign>
{{ :en:iot-reloaded:product_design.svg?800 |General Product Design Stages}}
<caption>General Product Design Stages</caption>
</figure>


==== 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 ((figure {{ref>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 sequentially, similar to V-shape, thus the name. The actual design process runs through several 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. The figure below presents the IoT system design adapted to the V-model. 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.

<figure v-model>
{{ :en:iot-reloaded:v-model.svg?600 |V-model for IoT systems}}
<caption>V-model for IoT systems</caption>
</figure>

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 analysed 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 system architecture and design, which is 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. Integration and validation will follow once the domain-specific solutions are ready at the specified maturity. The final step before the first prototype solution is complete system testing and again verifying and validating according to the system requirements.

The whole process may be repeated as often as necessary, depending on the final system's maturity level. If only proof of concept is needed, one iteration might be enough—frequently the case for educational projects. However, for real customer systems, many V-cycle 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 are standard 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 difficulties similar to those of mechatronic and software system design. Some relevant vital elements to address when designing and deploying a new IoT system:

  * New IoT systems often require organisational and working culture changes, which are usually underestimated. Changing workers' mindsets to collaborate with new IoT systems might be a critical issue frequently underestimated during design.
  * Due to their complexity 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, some of which might not be available, such as 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 many protocols, network architectures, and even electrical connectors may fail.
  * Data security is often underestimated. IoT systems are not standalone but, in most cases, interconnected through the public internet. 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.

<WRAP excludefrompdf>
The following chapters contain more details:
    * [[en:iot-reloaded:iot_system_design_principles]]
    * [[en:iot-reloaded:iot_system_design_goals]]
    * [[en:iot-reloaded:iot_system_design_challenges]]
    * [[en:iot-reloaded:systems_thinking_and_design_of_iot_systems]]
    * [[en:iot-reloaded:industrial_iot_systems]]
    * [[en:iot-reloaded:systems_modelling_using_sysml]]
</WRAP>