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) ¹⁾. 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> <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.