# Converging Telco-Grade Solutions 5G and beyond to Support Production in Industry 4.0
## 3 Modeling Approaches and Frameworks in the Field of Industrial IoT
### MDE-to-IoT Challenges
#### 3.2.1 Handling Heterogeneity through Abstraction  
The alpha and omega of any kind of system modeling, including the modeling of complex IoT systems, is conquering complexity by selecting the appropriate level of abstraction for the problem domain being analyzed. IoT is one of the most rapidly growing areas of the industrial technology. However, the way IoT is evolving raises serious concerns: there are far too many complexities, moving parts, diversities, and competing trends and technologies to consider when developing IoT solutions. One practical approach to dealing with the complexities of IoT would be to use the concept of _abstraction_ to create solutions that can deal with issues and diversities at different levels while remaining flexible in the face of constant changes. Through the activity of _modeling_, abstraction can help with the specification and design of complex IoT systems. The chosen tools and approaches provide various modeling facilities to aid in the specification and design of complex IoT systems. In this section, we summarize and evaluate the modeling languages that the various tools support for dealing with heterogeneity. In Papyrus, system requirements can be specified using UML use case diagrams [42] and SysML requirements diagrams [47]. The IoT system's use cases can be formally described and derived from the purpose and requirements specification. After defining the requirements, the functional architecture of the system can be defined using the IoTdomain model, which is provided as an extension of MARTE [48] and SysML. Aside from defining the functional architecture of the system, the operational platform on which the functional system will be executed must also be defined. The system's operational view includes information about computing devices, sensors, actuators, and communication protocols. Finally, using the Papyrus Designer Component, one must define deployment plans that include information on the allocation of functional blocks to operational ones. Finally, Papyrus provides modeling solutions that can deal with issues and diversity at various levels: it allows you to specify, design, and deploy IoT systems. The Eclipse 4 diac platform is based on the IEC61499 standard, which defines a domain-specific modeling language for developing distributed industrial control solutions in IoT. The IEC61499 standard includes several languages that can be used to program higher-level industrial control applications. The main components of the IEC61499 standard are: (i) Graphical language for programmable logic controller design that can describe the function between input variables and output variables, (ii) Graphical Execution Control Chart (ECC) of basic functional blocks that determines the algorithm to execute based on the current input event and data variables, and (iii) Structured Text (ST), which can be used to describe the function blocks' algorithms. Remember that the scope of Eclipse 4 diac differs from that of Papyrus. While Papyrus provides an abstraction for specifying, designing, and deploying IoT systems, the modeling languages implemented in Eclipse 4 diac target a narrower domain, only facilitating the development of distributed control solutions in industrial IoT. For the creation of Information Models, Eclipse Votto provides two options: (i) Graphical DSL (based on Eclipse Sirius [49]) aimed at business users with no or little programming experience and (ii) Textual DSL (based on Eclipse Xtext [50]) aimed at developers with an IT background. The information models in both languages are built from reusable, abstract, and technology-agnostic Function Blocks. The IoT system is described in FRASAD using a rule-based model and a textual DSL, allowing system designers to describe their IoT application using only sensor network domain concepts. The DSL aims to decouple programming languages and their execution models from the underlying operating system and hardware.