دانلود مقاله مدیریت پیچیدگی مدل‌های داده و عملکرد در معماری مبتنی بر کارگزار اینترنت از اشیا
خلاصه
1. معرفی
2. تجزیه و تحلیل نیازمندی ها
3. نمای کلی معماری برای قابلیت همکاری
4. برداشت خودکار مدل های داده
5. ارزیابی و اعتبارسنجی عملکرد
6. نتیجه گیری
اعلامیه منافع رقابتی
سپاسگزاریها
در دسترس بودن داده ها
منابع
Abstract
1. Introduction
2. Requirements analysis
3. Architecture overview for interoperability
4. Automated harvesting of data models
5. Performance assessment and validation
6. Conclusions
Declaration of Competing Interest
Acknowledgements
Data availability
References
چکیده
اینترنت اشیا (IoT) در حال فراگیر شدن است و با نصب هر پلتفرم جدید IoT، کارگزاران جدید و قدیمی باید مورد سوء استفاده قرار گیرند. کارگزاران داخلی جدید آنهایی هستند که تحت کنترل پلتفرم هستند، در حالی که کارگزاران خارجی قدیمی آنهایی هستند که توسط اشخاص ثالث مدیریت می شوند. راه حل پیشنهادی به مشکلات (الف) قابلیت همکاری برای کاهش زمان راه اندازی برای مقابله با ساختارهای داده ناشناخته (دستگاه ها، موجودیت ها) توزیع شده از طریق کارگزاران پرداخته است. (ب) عملکرد با ابعاد دادن به فرآیندهای فرانت‌اند و بک‌اند برای رسیدن به نرخ‌های بالا در یک پلتفرم مبتنی بر کارگزار، در حالی که ویژگی‌های قابلیت کامل انبار داده را حفظ می‌کند. جنبه‌های قابلیت همکاری با معرفی مفاهیم ما و یک دلیل در ابزار دایرکتوری اینترنت اشیا برای مدیریت کارگزاران داخلی و خارجی، کشف خودکار و ثبت دستگاه از هر دو مدل داده استاندارد و سفارشی، مورد بررسی قرار گرفته است. با وجود پیچیدگی مدیریت شده، یک راه حل مبتنی بر کارگزار عملکرد بالایی ارائه می دهد. برای این منظور، یک ارزیابی خاص و تنظیم معماری انجام شده و در مقاله برای ارائه شواهد و اعتبارسنجی گزارش شده است. دایرکتوری یکپارچه IoT پیشنهادی در چارچوب پروژه Herit-Data توسعه یافته است و در حال حاضر در کل شبکه Snap4City متشکل از 18 مستاجر و میلیاردها داده استفاده می شود. Snap4City یک پلتفرم IoT منبع باز برای شهرهای هوشمند و صنعت 4.0 است که یک پلتفرم و راه حل رسمی FIWARE، سرویس EOSC و لبه های Node-RED است.
Abstract
The Internet of Things (IoT) is becoming pervasive and with each new installation of IoT platforms new and legacy brokers have to be exploited. New internal brokers are those under the control of the platform, while legacy external brokers are those in place managed by third parties. The solution proposed addressed problems of (a) interoperability to reduce set up time to cope with unknown data structures (devices, entities) distributed via brokers; (b) performance by dimensioning both front-end and back-end processes to reach high rates in a broker-based platform, while preserving full capability features of the data warehouse. Interoperability aspects have been addressed by introducing our concepts and a reasoner into an IoT Directory tool to manage Internal and External brokers, automate device discovery and registration from both standard and customized data models. Despite the managed complexity, a broker-based solution turned out to provide high performance. To this end, a specific assessment and architecture tuning have been performed and reported in the paper to give evidence and validation. The proposed integrated IoT Directory has been developed in the context of the Herit-Data Project, and it is currently used in the whole Snap4City network of 18 tenants and billions of data. Snap4City is an open-source IoT platform for Smart Cities and Industry 4.0, which is an official FIWARE platform and solution, EOSC service and libs of Node-RED.
Introduction
The Internet of Things (IoT) defined a paradigm for the computation and communication amongst things, which is becoming every day more and more pervasive and adopted in many different domains [1,2]. It is partially due to the worldwide intense deployment campaign about Low-Power Wide Area Network technologies [3], as well as to many approaches and protocols for communications amongst devices (e.g., Message Queue Telemetry Transport or MQTT, Next Generation Service Interfaces or NGSI, Advanced Message Queuing Protocol or AMQP, Constrained Application Protocol or COAP). The approach is also covering the cloud and fog infrastructures [4,5]. Thus, IoT network infrastructures are becoming every day more complex to be managed due to the networks’ structure and existence of several protocols, formats, and concepts [1,6]. Hence, the complexity is growing in terms of data management, not only for huge amount of data but also for interoperability and abstraction levels needed to data managing. Relevant aspects to be considered are security and privacy [7] on specific data models and entities. To increase the complexity, there is a range of different owners and managers who may control different parts of such IoT networks [8].
In this context, the concept of Gateway is relevant for any segments of IoT networks connecting, as well as for the Web of Things, WoT [9]. Gateways may be integrated with one or more Brokers to send/receive data to/from Devices/entities. The Gateways and Brokers are typically compliant with a single protocol and may be managed by third parties with respect to data management platform. In some cases, they are provided as public services for several interested customers in the same area (for example: Proximus for LoraWAN services [10]). A Gateway may abstract from the IoT Broker level managing multiple brokers for multiple organizations/tenants (which can be regarded as customers of Gateway services to manage several Devices), via some API and/or Web user interface. Typical IoT Brokers can only manage one organization, and thus are single tenant, meaning they broker messages using topic/entity concepts (which can be regarded as the key for subscription on that specific device/entity) without any internal partition of services, but as a sort of family of devices and subscriptions. Some IoT Brokers can be multi-tenant, such as the FIWARE Orion Broker [11,12], which provides support for partitioning the served devices/entities/topics in groups, and each of them may have a dedicated service/path for a specific scope (or a specific customer). Furthermore, devices of different tenants could exist physically in different places (even having identical identifiers, IDs), and the subscription to the broker's tenant may imply receiving all messages/services in the partition in push. That is feasible only if the subscriber knows the service/path identifier and, in the event of access control, the subscriber has the grant to access the broker's services. Different IoT Devices connected to the same broker adopt the same protocol, may use different data structures/models and have the same semantic information.
Conclusions
The proliferation of IoT devices, brokers, networks, data models, operators and tenants, makes the harmonization and management of IoT Platform a hard goal. This paper offers an analysis and a comparison amongst relevant existing platforms, and it points out the basic requirements to achieve such aims. These identified requirements are in most cases not addressed by main platforms which prefer to stay on their own end-to-end solutions with limited interoperability and capacity of exploiting legacy IoT networks in place, in terms of performance. The proposed solution addressed problems of (a) interoperability by reducing set up time to efficiently detect and learn how to process unknown data structures (devices, entities) distributed via brokers; (b) performance by dimensioning the front-end and back-end processes to reach high rates in a broker-based platform, while preserving full capabilities features of data warehouse.
As to interoperability, the main identified and solved problems are those related to a large variety of Data Models coming from non-controllable External Brokers. The issue has been solved by designing and implementing a harvester and reasoner that is capable to automatically recognize/understand and map the new data models/types into those already known by Knowledge Base. This approach, together with the definition of a comprehensive meta model and dictionary, has allowed to speed up the process more than 800 times. The harvesting and comprehension process can be periodically performed to keep the platform updated with any newly defined data models by third party brokers. Furthermore, the process is helped by Km4City ontology and Data Dictionary to recognize the new data types and models according to the semantic domain.