Alexander Soldatov
email: soldatov.a@samsung.com

Gleb Balykov
email: g.balykov@samsung.com

Anton Zhukov
email: a.zhukov@samsung.com

Elena Shapovalova
email: elena.sh@samsung.com

Evgeny Pavlov
email: e.pavlov@samsung.com

.NET Runtime and Tools for Tizen Operating System

Keywords: Managed Programming Language, Compiler, Language Runtime, .NET

Samsung Electronics and Microsoft Corporation have been developing open source implementation of .NET platform called .NET Core since 2016. This platform is usually used for implementation of server-side and desktop applications, and Samsung has also adopted .NET Core virtual machine and libraries for Tizen OS. This solution was integrated into various ARM CPU based devices e.g. smart watches, TVs and other electronic devices. Tizen has always supported variety of languages and SDKs for developers. .NET has greatly expanded this variety by supporting new tools and new languages. This paper describes major challenges that we have encountered during integration of .NET to Tizen OS as well as optimizations, which were applied to .NET Core to make applications startup and memory consumption better on variety of devices.

Introduction

Throughout the long history of Tizen [5], variety of different technologies and languages were available to application developers. Initially developers were provided with native SDK with C/C++ support. This solution has demonstrated good performance and memory consumption of applications, but currently C/C++ languages are not very popular anymore because of difficulty of development. They require long development cycle and provide poor memory safety.

Web applications propose another approach to applications development on Tizen. While JavaScript and HTML5 gained popularity, this approach became very attractive. It allows to create applications very easily and fast. However, this approach is not effective in terms of hardware resources usage, specifically, startup time and memory consumption. Native applications are much better optimized and customized in comparison with web-applications. These metrics are essential for consumer electronics, thus web-applications can not be chosen as the most satisfying development solution.

.NET Core [START_REF]NET official homepage[END_REF] and C# language mitigate problems of the two approaches described above. They provide reach set of features and frameworks for application developers and demonstrate good performance and memory consumption. Table 1 shows comparison for different languages and technologies on the Samsung Galaxy Gear Watch 2 with Tizen 5.0 and Stopwatch application. Moving an ecosystem to a new operating system and CPU requires a large amount of work and optimization of existing code base. For example, the following parts of virtual machine should be updated or created from scratch: JIT compiler, low level code of virtual machine, which deals with operating system, parts of frameworks interacting with hardware. Furthermore, development tools like debuggers and profilers should also be created for non-supported operating system. All this work has been done for Tizen and ARM CPU, as well as Tizen specific performance optimizations, which allowed to deploy .NET Core on devices with small amount of memory and low-and mid-level CPUs. The details of those optimizations will be described below.

The goal of this paper is to describe Tizen .NET implementation specifics, both of virtual machine and developer tools. Section 2 describes high-level Tizen .NET architecture, with details of .NET Core virtual machine architecture. Section 2.1 includes high-level overview of .NET Core and Tizen optimization details. Section 2.2 describes Tizen-specific development tools.

Architecture

Figure 1 shows high level architecture of Tizen .NET platform. All three types of application development technologies used with Tizen rely on native subsystems, giving applications access to different parts of the device. CoreCLR virtual machine [START_REF]CoreCLR github[END_REF] and CoreFX basic libraries [START_REF]CoreFX github[END_REF] are the foundation of the .NET ecosystem in Tizen. They interact with operating system directly and allow to execute user's code. TizenFX and Xamarin.Forms are situated on the next level. These are the frameworks which provide additional functionality for developers and allow them to create user interfaces and utilize platform specific functionality from C# code.

Tizen uses special launchers for different types of applications. .NET specific launcher is called dotnet-launcher. It performs initialization of CoreCLR and Fig. 1. Tizen .NET architecture some additional activities (that will be described below) inside a candidate process before the application to be launched is determined. When request to launch application comes, the candidate process with prepared runtime already exists.

.NET Runtime

Main part of work related to enabling of .NET Core on Tizen was performed in runtime, specifically, in JIT compiler. JIT translates stack-based Microsoft Intermediate Language (MSIL) bytecode to the target CPU machine code and applies various optimizations. RyuJIT was chosen as a compiler, but it didn't support ARM. As this support is required for Tizen, it had to be implemented from scratch.

During this work all of the stages of compilation, that precede Code Generation, had to be updated to support ARM. Then some performance and memory consumption optimizations were applied. .NET Core versions differ in performance and memory consumption, thus optimizations applied were not universal.

Removal of relocations. This optimization reduces memory consumption. It turns out that some applications use the same libraries while being launched. So CoreCLR loads system libraries (DLLs) using mmap system call. Then those libraries may be shared between the applications. These DLLs are read-only, but they can be compiled to native images. Native images contain relocations, i.e. data or code, which rely on the actual starting memory address of mmapped file. This data or code should be updated at DLL load time, creating process specific copies of memory pages. The idea of optimization is to reduce number of such relocations making memory pages position independent and read only and, thus, shared between processes. This has been performed for various parts of native images and reduced CoreCLR Private memory consumption of each process by 45% (3 Mb) in average.

Direct mapping of assemblies. Previously, plain DLLs with section alignment smaller than a size of a virtual page had to be copied to anonymous memory. This means that each process will contain its own copy of DLL in physical memory. After optimization DLLs without writable sections (this is the case on Tizen) are directly mmaped to the memory. This is the optimization, which made managed DLLs shareable between processes in the first place. After this optimization CoreCLR Private memory consumption of each process was reduced by 9% (645 Kb) in average.

Simplification of allocators.

CoreCLR has many different allocators in different parts, and each allocator serves its purpose. One of the optimized allocators has been simplified to plain malloc/free allocator instead of the allocator with default prealloced memory, and this had no effect on performance. The other one (arena allocator) is used by JIT during compilation and never frees its memory by default. This behavior was changed to basically the same malloc/free and also had no negative effect on performance. Optimization of the former reduced CoreCLR Private memory of the application process by 11.5% (776 Kb) in average, optimization of the latter reduced Private memory of the whole application process by 8% (1.2 Mb) in average.

Compact entry points.

CoreCLR uses small thunks of code to perform call indirection, for example, to trigger compilation of method when it is called for the first time. This way a unique entry point is assigned to each method. There are different types of these thunks, e.g. FixupPrecode, StubPrecode or Compact entry points. Compact entry points are designed to occupy as little memory as possible by combining some of the auxiliary data of few methods (see listing 1.1). Each compact entry point on ARM occupies 4 bytes and CentralJump is 14 bytes. In comparison, each FixupPrecode occupies 12 bytes and its equivalent to CentraJump is 4 bytes. Previously, Compact entry points were not implemented for ARM, and their implementation reduced CoreCLR Private memory of the process by 2.2% (80 kb) in average. Besides, some micro benchmarks showed 15% improvement of performance.

CoreCLR initialization in candidate process. Previously CoreCLR was initialized after the application launch request is sent to dotnet-launcher (launcher of C# applications). It consumed startup time observed by users. To improve this point, CoreCLR initialization is now performed before application launch request is received (see figure 2). Runtime becomes prepared to launch actual application, mitigating runtime initialization time.

Fig. 2. CoreCLR initialization in candidate process

Class preloading. Since runtime is now initialized prior to the application launch request and there is some time before this request will actually come in, we can do some additional initialization. The idea of this optimization was to load some common DLLs and C# classes from libraries to memory even before the application launch request. When the class loading for application is performed, some of the classes will already be loaded to memory, thus startup time will be smaller. This optimization reduced startup time of applications by 3.7% in average. Hydra launcher. We can go even further with the work we do prior to application launch request. In case the Linux process mmaps native images to memory, then applies relocations and then performs fork, all these dirty memory pages move to the Shared part of memory of all child processes, i.e. only one copy of these memory pages will exist in physical memory, thus reducing memory consumption. By applying the same technique and creating additional parent process called Hydra, which mmaps native images of system DLLs to memory and applies relocations to them, we were able to reduce memory consumption of the whole application process by 14% in average.

.NET Tools

This section provides a brief review on .NET tools provided by Samsung. Visual Studio Plugin for Tizen [START_REF]Samsung Visual Studio Tools for Tizen[END_REF] is one of major tools for Tizen developers. This plugin includes two components: NetcoreDBG [4] (debugger) and Performance profiler [START_REF] Samsung | NET Performance Profiler manual[END_REF]. Both these components were developed from scratch as open source projects.

Samsung NetcoreDBG debugger. This debugger was developed as an alternative managed debugger for .NET applications. Microsoft provides proprietary debugger (VSDBG) for this purpose, but it sets several limitations: it is compatible with VSCode IDE or Microsoft Visual Studio only; it does not support ARM architecture. NetcoreDBG overcomes these limitations: it may be used in several OS-es (MS Windows, Linux, Tizen, Mac OS) and it supports various architectures (x86, ARM, x64).

Samsung C# profilers. The two major profiling opportunities are performance and memory profiling. The data gathered by profilers is processed and presented in a graphical interface of VS plugin.

The performance profiling mode shows real-time memory usage as well as CPU load. Also it allows to track JIT and GC events depending on the profiling options.

Memory profiler shows amount of dynamically allocated memory by user code and by runtime itself. The allocated memory is classified as Heap Allocated, Heap reserved, unmanaged memory and Span (memory allocated by data type during application lifespan).

Conclusion

This paper describes major challenges that we have encountered during integration of .NET on Tizen operating system as well as optimizations, applied to .NET Core to make applications startup and memory consumption better. Further plans are related to the support of new versions of .NET Core and implementation of new ARM-specific optimizations for newest Tizen releases.

Table 1 .

 1 Comparison of Tizen developer technologies

	Technology/Function Native Web applications .NET Core
	Memory usage	8.6 MB	65.4 MB	27.3 MB
	Application startup time 0.4 sec	1.2 sec	1.0 sec
	Memory safety	No	Yes	Yes


Andrey Tarasiev

Margarita Filippova

Konstantin Aksyonov

Olga Aksyonova

Anna Antonova
email: antonovaannas@gmail.com

Using of Open-source Technologies for the Design and Development of a Speech Processing System Based on Stemming Methods

Keywords: Multi-Agent, Design, Development, System, Decision-Making, Real-Time, Twin, Stemming, Postprocessing, Open-source

This article discusses the idea of developing an intelligent and customizable automated system for real-time text and voice dialogs with the user. This system can be used for almost any subject area, for example, to create an automated robot -a call center operator or smart chat bots, assistants, and so on. This article presents the developed flexible architecture of the proposed system. The system has many independent submodules. These modules work as interacting microservices and use several speech recognition schemes, including a decision support submodule, third-party speech recognition systems and a postprocessing subsystem. In this paper, the post-processing module of the recognized text is presented in detail on the example of Russian and English dictionary models. The proposed submodule also uses several processing steps, including the use of various stemming methods, the use of word stop-lists or other lexical structures, the use of stochastic keyword ranking using a weight table, etc.

Introduction

At a present day technologies related to automated control processing systems are rapidly developing. As a part of these modern trends in the development of information technology the creation of effective and technologically advanced solutions for organizing the processing of incoming requests is required Data processing technologies are progressively evolving, with more and more systems replacing human resources every day. Automation and the creation of information systems are at the moment the most promising areas of activity of modern society. One of the reasons for the active development of these areas is that automation is the basis for a fundamental change in management processes that play an important role in the activities of companies.

Thus, there is a need to use a control system, whose operation is aimed at maintaining and improving the operation of the all business processes at all.

As an important part of this area an automation of call centers working process require the help of a control device (complex of means for collecting, processing, transmitting information, and generating control signals or commands).

The module of speech recognition in this system uses the two most developed at the moment existing solutions YandexSpeechKit and GoogleSpeech API. But integration with these third-party services and other related solutions can't provide complete accordance with system requirements including features, adequate recognition quality, scalability, flexibility and so on.

As previous part of this work the testing of the speech recognition systems using Russian language models including selecting and testing a speech recognition systems and designing architecture of the "Twin" automation system was conducted [START_REF] Tarasiev | Development of an Intelligent Automated System for Dialogue and Decision-Making in Real Time[END_REF].

Based on the received information, we can conclude that the Yandex system is good at recognizing short expressive phrases, as well as numerals. On contrary, the Google API is good at recognizing long phrases and terms. The results of this research are being used in development of the automatic system that calls the customers of "Twin" [START_REF] Aksyonov | Testing of the speech recognition systems using Russian language models[END_REF][START_REF] Aksyonov | Development of decision making software agent for efficiency indicators system of IT-specialists[END_REF][START_REF]Features of TWIN[END_REF]. At the same time, both systems have problems with recognition in terms of noise, uneasy speech tempo and voice defects of the interlocutor.

Development experience of answer and question automated systems are described in some works: based on frame approach [START_REF] Minsky | A framework for Representing Knowledge in The Psychology of Computer Vision[END_REF], based on agent approach [START_REF] Greenwald | Guest Editors' Introduction: Agents and Markets[END_REF][START_REF] Dash | Computationals-Mechanism Design: A Call to Arms[END_REF][START_REF] Vittikh | Multiagent Interaction Models for Constructing the Needsand-Means Networks in Open Systems[END_REF] and conceptual graphs [START_REF] Sowa | Knowledge Representation: Logical, Philosophical, and Computational Foundations[END_REF][START_REF] Sowa | Conceptual graphs for a database interface[END_REF][START_REF] Sowa | Conceptual Structures: Information Processing in Mind and Machine[END_REF]. This is due to the fact that both systems better recognize phonemes and phrases, and individual sounds are worse, especially if there are noises and other factors that distort the quality of the transmitted audio message. This observation is confirmed by the findings obtained by other independent researchers [START_REF]The study of the reliability of speech recognition by the system Google Voice Search[END_REF].

To eliminate such problems, it is necessary to include pre-and post-processing. These actions can provide requirements of recognition quality.

Pre-processing uses the dynamic selection of recognition services provided. Subsequent processing of the received textual information includes the lemmatization and normalization of individual words in the recognized speech and other methods. For example, in the case of processing numbers, this is the application of tokenization technology.

Also in previous part of this work the research and selection of methods for evaluating information about part of speech, word form and statistical relationships between words have been done.

As the conclusion of this research we can claim that the lemmatization method is most effective for solving the problems of dynamic text processing and recognition. However, to the same extent, this approach is extremely dependent on the exact definition of a part of speech (the lexical category of a word) and the language model. Application of this algorithm leads to the fact that the analyzer module receives an array of words in primary form, due to which it is possible to easily recognize part of speech using the rules of the language model. However, this information in practice may not be enough for the further work of the decision-making module and generating a response. In addition, there is the possi-bility of recognition errors associated with incorrect recognition of the lexical category of a word and its initial form.

To obtain a more accurate recognition and processing result, further postprocessing mechanisms are used.

The implementation of the lemmatization mechanism in the system was performed through some open-source package solutions of morphological processing and lemmatization for the PHP language.

Within the framework of this work, the design and development of an automated system named "Twin" was carried out and details presents module of recognized text post-processing on the example of the Russian and English languages dictionary models.

Integration of Speech Recognition Functionality With Ranking and Database Generation Functionality

Since the approach of reducing the words to normal form and determining the parts of speech is insufficient for the voice robot to understand the interlocutor's speech and for further decision making, the system uses post-processing algorithms for normalized words. This is due to the presence of a number of problems, inaccuracies and recognition errors.

In addition, the lemmatization method can occur recognition errors since the lexical category of a word can be incorrectly determined. There is also a big problem with the correct recognition of numerals, which leads to difficulty to identifying numbers, dates, addresses, etc. To solve these problems, several additional processing algorithms are used.

Many researchers provide several methods to improve quality of natural language processing based on stemming methods.

When building the speech recognition module for voice system, we were guided for the most part not by coming up with conceptually new algorithms, but by focusing on the use and adaptation of existing and well-established approaches.

The most often usable method based on implementation of a large vocabulary speech recognition system for the inflectional languages such as Slavic group languages [START_REF] Rotovnik | Large vocabulary continuous speech recognition of an inflected language using stems[END_REF].

Based on this approach the following method for additional processing was proposed.

Conventionally, we can distinguish the following steps of the additional processing of the second stage:  primary processing;  introduction of a keyword system and the use of stochastic keyword ranking;  introduction of a word stop-list system.

Primary Processing

Decisions on the basic additional processing of normalized words are determined on the basis of the given settings and information on the lexical category of the word (part of speech) as a preparatory stage for more serious text analysis methods.

The essence of the primary processing of the second stage of text analysis is the use of simple algorithms for automated morphological analysis.

To increase the accuracy of recognition of numerals, the information contains numerals goes through the tokenization procedure. Also, the system provides for the adjustment of language models, which allows you to customize the perception of numerals, dates, cases, as well as the need to use keywords. In addition, it is possible to configure the methods used for stemming.

Application of the Keyword System

The introduction of a keyword system allows for significantly more effective recognition of language units. Firstly, this is due to the fact that keywords can be tied to specific blocks of the dialogue script, which largely solves the problems associated with the context. This can be useful, for example, when processing paronyms.

When creating a script in a special interface, creator of the scenario can set keywords for each person's answer.

This dialogue scenario consists of various information blocks, most of which involve the interlocutor's response or expectation of a phrase.

Moreover, depending on the frequency of mentioning of certain words and phrases, further training takes place. The system, each time making a decision, increases the weight of a certain keyword in the expert table of stochastic data. Thus, the likelihood of a particular word appearing during further launches of this dialogue scenario increases depending on the frequency of its appearance and correct recognition earlier.

The processed text is transferred to the block of the analyzer of coincidence with keywords.

At the same time, both processed normalized words and initially recognized words are transmitted to the system. Keywords themselves can be set intentionally in various forms. Due to these two conditions, the recognition quality can be significantly improved, and the table of knowledge base weights for the stochastic ranking method will be more trained. A similar approach is widespread in systems using stochastic knowledge bases.

In addition, this makes it easy to solve the potential problem of the loss or distortion of the meaning of either a single word or the phrase itself as a whole.

That is, if several variants of the same word are specified in the system for a certain block of the script, and both coincide with the original and lemmatized recognized words, then the probability weights for both keywords will significantly increase, and the weight of the script branch will also increase by the weight of both keywords.

By default, the conditional weight of each keyword and each branch of the dialogue at the initial moment of execution time of a script is equal to one. When the lemmatized word coincides with the originally recognized word with the keywords, the weight of each keyword increases by one. In this case, the weight of the branch increases by two units. If only the keyword denoting the initial form and the lemmatized language unit coincide, then the weight of the script dialog branch increases by one.

Based on the dynamically calculated weights of each branch, at every moment a decision is made on the further development of the dialogue scenario taking into account the largest branch weight.

This approach allows the author of the script to work out the dialogue features important for the script, which are influenced by the degree and conjugation of the verb, etc.

As already mentioned, in addition to setting keywords the system provides for the use of tables of stochastic ranking of words by probability depending on the frequency of their appearance and correct recognition in dialogs.

Of course, to ensure the correct operation of such a system, it is necessary to implement and maintain a knowledge base. It is worth noting that this storage takes up much less volume than other knowledge base implementations for stochastic stemming methods would occupy. To ensure dynamic interaction, in the system it is implemented as a base tree.

The use of the stochastic method is primarily due to the fact that an approach that implements only lemmatization algorithms is not able to provide sufficient reliability for correct speech recognition and decision making, since it places great responsibility on the system operator itself, which may be mistaken due to the human factor or not take into account all the options, which can have a big impact on the course of the dialogue.

Application of the Stop-word System

Similar to using the keyword system in a word processing module, stop words are also used. Their semantic load is similar to keywords. The essence of this idea is to strictly discard branches when the recognized word coincides with the stop word. This approach allows us to simplify the writing of some dialogue scenarios by providing the user with the opportunity to work with negation and exceptional situations, or to write down fewer keywords and work out less on premediating of potential scenarios. It also allows to speed up the processing of text, due to the fact that some cases can be immediately discarded and not be considered in the future.

According to the implementation method, the process of recognizing stop words is practically no different from keywords. A lemmatized word and a primary word are transmitted to the handler in their original form recognized by an external opensource morphy system. These words are compared with stop words. If a match is found, the weight of the stop word in the knowledge base of stochastic rules increases, and the weight of the branch decreases to the minimum possible. Thus, during the execution of the further procedure for selecting a scenario vector, this branch cannot be selected in any way.

After applying all the rules and treatments, the search for a solution begins in accordance with the rules specified in the script, after which a response is generated.

Recognition Process Description

Based on everything described earlier, a simplified process of additional processing of a phrase recognized by third-party systems occurs as follows: At the first step, the text recognized by a third-party system is transmitted to the post-processing module. This module analyzes this text in several stages.

First of all, the text goes through the procedure of splitting into separate linguistic units -words and statistical grouping by phrases. Each word is lemmatized, as a result of which the word in the initial form is returned at the output of the work of the stemming algorithms, and the lexical category of the word is also determined.

Next, the second stage of processing begins. Based on the part of speech defined in the previous step, initial processing is performed. In this case, the rules defined when setting up language models are used, such as processing numerals, tokenization, processing dates, cases for nouns, etc.

The processed words and words in their original form, recognized by third-party systems, are transferred to the next data processor, which deals with their comparison with keywords and stop words, which are pre-introduced to the system for the corresponding blocks of the dialogue script.

If the words transmitted to the input of the algorithm coincide with the ones specified in the system, the statistical weights of the keywords and corresponding branches of the script increase.

The weights of the words specified in the system are recorded in the production knowledge base of stochastic rules. Thus, the ranking of words is provided and the model is trained. The more often these or other words and phrases are used when executing a script during dialogs, the more likely it is the appearance of these words in these forms with other passages of this scenario. Accordingly, over time, these words will be more correctly recognized.

Finally, based on which branch, illustrating the possible choice of further development of the dialogue, is gaining the greatest weight, a decision is made and a response is generated.

This process can be visualized using the following sequence diagram (see Fig. 1). We are considering options for highlighting our own developments, such as a system of keywords, into separate freely distributed solutions.

Using of Open-source Technologies to Development Postprocessing System

The implementation of the lemmatization mechanism in the system was performed through an open-source package solution of morphological processing and lemmatization for the PHP language -PHP Morphy, which contains the corresponding knowledge bases -dictionaries for various language models. This solution easily integrates with the used development tool stack. This library supports AOT and myspell project dictionaries. For the library to work, you need to compile a binary dictionary. When compiling, the dictionary is used in its original form.

Physically, the dictionary is presented in the form of several files, which are a data store in a key-value format, as well as storage of reference lexical information, grammatical information, end tables, grammes, etc.

Other word processing packages for processing declension cases, such as petrovitch library also are used. This package also allows to gender determination and develop and apply own linguistic rules.

It should be noted that using of open-source systems in not limited by mentioned solutions.

Flexibility of proposed application and modern technologies itself allows to simple scaling or replacing third-party modules or adding new.

Moreover, proposed dialogue systems use other open-source packages for different modules that are not limited to post-processing speech recognition module.

For example, we use Rasa Core module for speech-analyze subsystem and chatbots.

Mentioned speech-analyze subsystem using as a part of customizable script.

Conclusion

Open-source solutions provide ability to integrate various implementations of exists methods, such as stemming text recognition methods in proposed case, with each other and own development.

Due to additional processing, the correct perception of speech and the meaning of what has been said and decision-making occurs in developing system.

The development of the system involves the development and implementation of additional functions, such as the sending of statistical data and the creation of hints in the compilation of the script. To do this exists open-source solutions also can be used. Analysis of internal statistics will help determine the priority directions for improving the interface and system features.

The range of use of the system can be extended, due to the initial flexibility of the structure and wide ability to integrate with third-party solutions, packages and so on.

It should be noted that proposed system Twin is used in teaching intellectual technologies at the Ural Federal University on a free basis.

We are considering options for highlighting our own developments, such as a system of keywords, into separate freely distributed solutions.

Fig. 1 .

 1 Fig. 1. Sequence diagram for additional post-processing of recognized text.

Acknowledgments

The work was supported by Act 211 Government of the Russian Federation, contract no. 02.A03.21.0006.


Daniel Atonge
email: d.atonge@innopolis.university

Vladimir Ivanov

Artem Kruglov

Ilya Khomyakov

Andrey Sadovukh

Dragos Strugar

Giancarlo Succi

Xavier Zelada Vasquez

Evgeny Zouev

The development of data collectors in open-source system for energy efficiency assessment

Keywords: Process metrics, Energy metrics, Collector, Windows, macOS, Open source software

The paper is devoted to the development of the data collectors for Windows OS and MacOS. The purpose of these plugins is to collect the process metrics from the user's device and send it to the backend for further processing. The overall open source framework is aimed at energy efficiency analysis of the developing software products. The development presented here as a sequence of the life cycle stages, including requirements analysis, design, implementation and testing. Specifics of the implementation for each targeted operating system are given.

Introduction

Modelling the energy consumption of applications, gathering valid data from active and passive application processes (i.e, applications in focus and idle applications) is a crucial activity which can be used to find correlations and trends in various areas of research such as developer's productivity, applications with the highest energy consumption profiles and more. To this aim, researchers have proposed hardware-based tools as well as model-based [START_REF] Kalaitzoglou | A practical model for evaluating the energy efficiency of software applications[END_REF] and software-based [START_REF] Kor | Applications, energy consumption, and measurement[END_REF] techniques to approximate the actual energy profile of applications. However, all these solutions present their own advantages and disadvantages. Hardwarebased tools are highly precise, but at the same time their use is bound to the acquisition of costly hardware components. Model-based tools require the calibration of parameters needed to correctly create a model on a specific hardware device. Software-based approaches are cheaper and easier to use than hardwarebased tools, but they are believed to be less precise. We present the collectors (Windows, MacOs), a software-based approach whose duty is to gather all valuable data about active and passively running applications together with energy based metrics. This data when collected can later be processed on the server and Supported by the Russian Science Foundation grant result in precise trends and predictions which could enormously benefit software development teams. Making it Open Source exhibits several advantages, as evidenced in several scientific venues [START_REF] Kovács | Open Source Software for the Public Administration[END_REF][START_REF] Rossi | Modelling Failures Occurrences of Open Source Software with Reliability Growth[END_REF][START_REF] Fitzgerald | Adopting open source software: A practical guide[END_REF][START_REF] Di Bella | A multivariate classification of open source developers[END_REF].

Collector Development

The development life-cycle of the collector applications were broken down into the various parts

Analysis

Before analysis of the application and design methods, we had a series of requirements both functional and non-functional that lead to the implementation of the current application [START_REF] Vernazza | Defining Metrics for Software Components[END_REF][START_REF] Scotto | A Relational Approach to Software Metrics[END_REF][START_REF] Sillitti | Measures for mobile users: an architecture[END_REF][START_REF] Corral | Software Assurance Practices for Mobile Applications[END_REF]. These requirements established the services that the client requires from our system and the constraints under which our system operates and is developed

The functional requirements are the following:

-The list of collected metrics should be easily modifiable -The metrics should be collected and send to DB automatically after authorization. -The time interval to send the data to server should be specifiable -The collector should support automatic updates -Clients should be able to send error reports -Energy related metrics should be collected -Product metrics should be collected -Collectors should implement search functionality Similarly, the non-functional requirements for the collector are the following:

-Modifiability -Maintainability -Adaptability -Security -Reusability -Reliability With these requirements in place, analysis of the developed application and documentation of the design decisions were made.

Analysis is that iterative process that continues until a preferred and acceptable solution or product emerges. During the analysis of our system, factual data was collected (i.e what is lacking, what was done, what is needed, e.t.c). Understanding the processes involved, identifying problems and recommending feasible suggestions for improving the systems' functioning was done. This involved studying logical processes, gathering operational data, understanding the information flow, finding out bottlenecks and evolving solutions for overcoming the weaknesses of the system so as to achieve the organizational goals for the collector. Furthermore, subdividing of complex processes involving the entire system and the identification of data store and manual processes where made.

During the early stages of development, we felt the need of a simple but purposeful representation of our entire system. This representation was needed in order to:

-Specify the context of our system -Capture system requirements -Validate systems architecture -Drive implementation and generate test cases This was more of a thinking process and involved the creative skills. We attempted to give ideas to an efficient system that satisfies the current needs of our clients and has scope for future growth within the organizational constraints.

Overall we followed an agile development process [START_REF] Sillitti | Service Oriented Programming: A New Paradigm of Software Reuse[END_REF][START_REF] Pedrycz | A model of job satisfaction for collaborative development processes[END_REF][START_REF] Sillitti | Understanding the Impact of Pair Programming on Developers Attention: A Case Study on a Large Industrial Experimentation[END_REF][START_REF] Coman | Cooperation, collaboration and pair-programming: Field studies on backup behavior[END_REF][START_REF] Janes | Lean Software Development in Action[END_REF], also employing techniques for Internet-based working [START_REF] Maurer | Software Process Support over the Internet[END_REF], and organizing our development using a component-based approach [START_REF] Sillitti | Service Oriented Programming: A New Paradigm of Software Reuse[END_REF].

Design

The system was designed to satisfy the requirements stated in the specifying stage. The requirements identified during Requirements Analysis were then transformed into a System Design Document [START_REF] Hao-Yu | Basic design principles in software engineering[END_REF] that accurately describes the design of the system and that can be used as an input to system development (see Fig. 2).

Implementation

The logical design was then implemented to build a workable system. This demands the coding of design into computer understandable language, i.e., programming language (in our case native and specific to the targeted platform). Here, program specifications were converted into computer instructions (programs). The programs written coordinate the data movements and control the entire process in our system. Having maintainability as one of our non-functional requirements, code was well written to reduces the testing and maintenance effort. This helps in fast development, maintenance and future changes, if required. We used Visual Studio Code 2019 and the C# programming language (for Windows OS), Xcode and Swift 4.0 (for MacOs) and lastly, QtCreator and C++ (for Linux)

We aim at gathering valuable data related to each running application process. We choose the following; process name, process id, status (app focus or idle), start time, end time, ip address, mac address, process description, processor, hard disk, memory, network and input/output usage.

The internal implementation includes external packages installed via NuGet like RestSharp, A powerful API that assist our application with sending request and reading responses from the server (in windows).

The collector is presently an application with the following interfaces:

-Registration interface for new users -The Login interface for existing users and -The Collector Interface: Which displays data collected from the host's machine

Testing

Before deciding to install our system and put it into operation, a test run of the system was done removing all the bugs as necessary. The output of all our test matched expected results. We ran the two categories of test:

-Program test: Referring to our requirements for expected results of our system, coding, compiling and running our executable was the routine. After our locally based collector application was up and running, each use-case of our system was tested to match expected outcome. We carried out various verification and noted unforeseen happenings which were eventually corrected.

-System test: After carrying out program test and errors removed, running the overall system with the back-end and making sure it meets the specified requirements was done. Our system was fully developed and ready for usage by clients

3 Integration with the back-end system

In order to be able to perform authenticated requests, such as sending the collected metrics, collectors should first authenticate with the back-end. That is performed using the POST HTTP request to the back-end system. Then, backend API requests the Auth Token from the Authentication Service, which is also a part of the back-end system. Then, the Auth Service gets the user information from the database, and if everything turns out to be alright, responds with the token to the collectors. Then, collectors perform the needed actions described in the sections above, i.e. primarily store the activities along with energy efficiency metrics locally. When the time comes to send the report to the back-end, the collector sends a POST HTTP request with the Auth Token to the back-end containing all the information about processes that were in use.

Back-end services, upon receiving the request from the collectors, validate the authenticity of the user and receives, and stores in the database the data sent by the collector.

The sequence diagram (see Fig. 3) showcases the above mentioned scenario, adding to the picture the Innometrics Dashboard, a go-to tool for managers to have an overview of the entire reporting process [START_REF] Ivanov | Design of a dashboard of software metrics for adaptable, energy efficient applications[END_REF]. This section provides with the peculiarities of developing the collectors for different types of OS. For now the collectors for Windows OS and MacOS are developed. Further, the collectors for X11 and Android OS are planned to be developed.

Specific of Windows OS collector

The collector is compose of 3 forms which will come up occasionally (i.e Account verification (at login) form, Registration form, Collector form). These are the only means of communication with the system from a user perspective.

In Code, best programming practices where used such as those specified by the object-oriented, service-oriented paradigm. Furthermore, good code related practices where enforced such as the DRY (Do Not Repeat Yourself) principle, Naming conventions and more [START_REF] Dooley | Software Development and Professional Practice[END_REF].

The main interface (Fig. 4), consists of table view, which is automatically updated by a running service to make sure our application does not block at any time and that, the user can always interact with the collector.

Data being collected by running services are the following; process name, process id, status (app focus or idle), start time, end time, ip address, mac address, process description, battery consumption. All other details have been well presented in the sections above Battery draining applications result in bad user experience and dissatisfied users. Optimal battery usage(energy usage) is an important aspect that every client must consider.

Application energy consumption is dependent on a wide variety of system resources and conditions. Energy consumption depends on, but is not limited to, the processor the device uses, memory architecture, the storage technologies used, the display technology used, the size of the display, the network interface that you are connected to, active sensors, and various conditions like the signal strength used for data transfer, user settings like screen brightness levels, and many more user and system settings.

For precise energy consumption measurements one needs specialized hardware. While they provide the best method to accurately measure energy consumption on a particular device, such a methodology is not scalable in practice, especially if such measurements have to be made on multiple devices. Even then, the measurements by themselves will not provide much insight into how your application contributed to the battery drain, making it hard to focus on any application optimization efforts [START_REF] Acar | The impact of source code in software on power consumption[END_REF].

The collector aims at enabling users to estimate their application's energy consumption without the need for specialized hardware. Such estimation is made possible using a software power model that has been trained on a reference device representative of the low powered devices applications might run on.

Using the PerformanceCounter, PerformanceCounterCategory and many more related classes (made available by the .NET Framework [3]), the energy usage can be computed. Performance counter(s) provided information such as CPU time, Total Processor Time per process, CPU usage, Memory usage, network usage and more. The MSDN documentation [START_REF]Microsoft, performance counters[END_REF] was used to better understand how we could utilise the available components in attaining our goal (collecting energy consumption metrics).

It is difficult to match up constantly changing application process IDs and names Imperfection in designed power model as energy consumption depends on a variety of factors not limited to those we can collect using these available performance classes

Specific of MacOS collector

The developed MacOS application is a status menu bar application, as shown in Fig. 5. The application shows the most important information about the user that is collecting the activities. It shows the currently running process, along with the time it is active. In background, it stores this data locally and prepares to send it to the back-end service, as described above.

A collection of information about the currently running process can be obtained using the NSProcessInfo class in the Task Management subsection of Foundation API. This includes thermal state, app performance as well as other specifics. It allows developers to track the information about an activity in the currently running application. However, the problem here arises when we want to access such information for other processes; MacOS has security built-in that does not allow our application to monitor such information.

MetricKit [1] came as a stable solution, that allowed us to aggregate and analyze per-device reports on power and performance metrics, particularly important for prediction [17, 20, 19, ?]. However, what it does it collects metrics and sends them once every 24 hours, and is thus not fully suitable to our case.

Thus, we have decided to exclude the CPU utilization, while other metrics, like battery power, memory, GPU and others are already in development and testing stage.

Conclusion

Our profiling method and the tools we have available are only able to attribute energy consumption at process level. Any finer granularity, although desirable, is not possible.

Hardware resource usage could fill the gap when it comes to accurately relating EC to individual software elements hence enabling us to compute the UEC.

Profiling the performance requires basic understanding of the hardware components that has to be monitored through "performance counters" in windows and when interpreting performance data for further analysis, context information has to be taken into account (e.g. hardware-specific details).

To evaluate Unit Energy Consumption we can monitor the following hardware resources [START_REF] Kor | Applications, energy consumption, and measurement[END_REF]: Hard disk: disk bytes/sec, disk read bytes/sec, disk write bytes/sec Processor: % processor usage Memory: private bytes, working set, private working set Network: bytes total/sec, bytes sent/sec, bytes received/sec IO: IO data (bytes/sec), IO read (bytes/sec), IO write (bytes/sec) Attributing some weights to elements of the UEC or by some reliable assumption such as considering the power model to be linear in nature for each individual component, We can compute the SEC Metric.

Reporting these metrics is also useful in identifying potential trade-offs between energy efficiency and other aspects of software quality (e.g. maintainability)

Fig. 1 .

 1 Fig. 1. Use case diagram for the collector

Fig. 2 .

 2 Fig. 2. Logical system design

Fig. 3 .

 3 Fig. 3. Logical system design

Fig. 4 .

 4 Fig. 4. Logical system design

Fig. 5 .

 5 Fig. 5. Logical system design

Acknowledgments

The work presented in this paper has been performed thanks to the support by the Russian Science Foundation grant No 19-19-00623.


Vasiliy N Kruglov
email: v.krouglov@mail.ru

Using open source libraries in the development of control systems based on machine vision

Keywords: Grain-size analysis, Machine vision, Object boundaries detection, Convolutional neural network, Open source libraries, Machine learning

The possibility of the boundaries detection in the images of crushed ore particles using a convolutional neural network is analyzed. The structure of the neural network is given. The construction of training and test datasets of ore particle images is described. Various modifications of the underlying neural network have been investigated. Experimental results are presented.

Introduction

When processing crushed ore mass at ore mining and processing enterprises, one of the main indicators of the quality of work of both equipment and personnel is the assessment of the size of the crushed material at each stage of the technological process. This is due to the need to reduce material and energy costs for the production of a product unit manufactured by the plant: concentrate, sinter or pellets.

The traditional approach to the problem of evaluating the size of crushed material is manual sampling with subsequent sieving with sieves of various sizes. The determination of the grain-size distribution of the crushed material in this way entails a number of negative factors:

the complexity of the measurement process; the inability to conduct objective measurements with sufficient frequency; the human error factor at the stages of both data collection and processing. These shortcomings do not allow you to quickly adjust the performance of crushing equipment. The need for obtaining data on the coarseness of crushed material in real time necessitated the creation of devices for in situ assessment of parameters such as the grain-size distribution of ore particles, weight-average ore particle and the percentage of the targeted class. The machine vision systems are able to provide such functionality. They have high reliability, performance and accuracy in determining the geometric dimensions of ore particles. At the moment, several vision systems have been developed and implemented for the operational control of the particle size distribution of crushed or granular material. In [START_REF] Thurley | Identifying, visualizing, and comparing regions in irregularly spaced 3d surface data[END_REF], a brief description and comparative analysis of such systems as: SPLIT, WIPFRAG, FRAGSCAN, CIAS, IPACS, TUCIPS is given.

Common to the algorithmic part of these systems is the stage of dividing the entire image of the crushed ore mass into fragments corresponding to individual particles with the subsequent determination of their geometric sizes. Such a segmentation procedure can be solved by different approaches, one of which is to highlight the boundaries between fragments of images of ore particles. Classical methods for borders highlighting based on the assessment of changes in brightness of neighboring pixels, which implies the use of mathematical algorithms based on differentiation [START_REF] Gonzalez | Digital Image Processing[END_REF][START_REF] Sonka | Image Processing, Analysis and Machine Vision[END_REF]. Fig. 1 shows typical images of crushed ore moving on a conveyor belt. This paper presents the results of recognizing the boundaries of images of stones based on a neural network. This approach has been less studied and described in the literature, however, it has recently acquired great significance in connection with its versatility and continues to actively develop with the increasing of a hardware performance [START_REF] Flach | Machine Learning: The Art and Science of Algorithms That Make Sense of Data[END_REF][START_REF] Gron | Hands-On Machine Learning with Scikit-Learn and TensorFlow: Concepts, Tools, and Techniques to Build Intelligent Systems[END_REF].

Main part

To build a neural network and apply machine learning methods, a sample of images of crushed ore stones in gray scale was formed . The recognition of the boundaries of the ore particles must be performed for stones of arbitrary size and configuration on a video frame with ratio 768x576 pixels.

To solve this problem with the help of neural networks, it is necessary to determine what type of neural network to use, what will be the input information and what result we want to get as the output of the neural network processing. Analysis of literary sources showed that convolutional neural networks are the most promising when processing images [START_REF] Flach | Machine Learning: The Art and Science of Algorithms That Make Sense of Data[END_REF][START_REF] Gron | Hands-On Machine Learning with Scikit-Learn and TensorFlow: Concepts, Tools, and Techniques to Build Intelligent Systems[END_REF][START_REF] Gulli | Deep learning with Keras: implement neural networks with Keras on Theano and TensorFlow[END_REF][START_REF] Saha | Comprehensive guide to convolutional neural networks -the eli5 way[END_REF].

Convolutional neural network is a special architecture of artificial neural networks aimed at efficient pattern recognition. This architecture manages to recognize objects in images much more accurately, since, unlike the multilayer perceptron, two-dimensional image topology is considered. At the same time, convolutional networks are resistant to small displacements, zooming, and rotation of objects in the input images. It is this type of neural network that will be used in constructing a model for recognizing boundary points of fragments of stone images.

Algorithms for extracting the boundaries of regions as source data use image regions having sizes of 3x3 or 5x5. If the algorithm provides for integration operations, then the window size increases. An analysis of the subject area for which this neural network is designed (a cascade of secondary and fine ore crushing) showed: for images of 768x576 pixels and visible images of ore pieces, it is preferable to analyze fragments with dimensions of 50x50 pixels.

Thus, the input data for constructing the boundaries of stones areas will be an array of images consisting of (768-50)*(576-50) = 377668 halftone fragments measuring 50x50 pixels. In each of these fragments, the central point either belongs to the boundary of the regions or not. Based on this assumption, all images can be divided into two classes.

To mark the images into classes on the source images, the borders of the stones were drawn using a red line with a width of 5 pixels . This procedure was performed manually with the Microsoft Paint program. An example of the original and marked image is shown in Fig. 2. Then Python script was a projected, which processed the original image to highlight 50x50 pixels fragments and based on the markup image sorted frag-ments into classes preserving them in different directories To write the scripts, we used the Python 3 programming language and the Jupyter Notebook IDE. Thus, two data samples were obtained: training dataset and test dataset for the assessment of the network accuracy.

As noted above, the architecture of the neural network was built on a convolutional principle. The structure of the basic network architecture is shown in Fig. 3 [7].

Fig. 3: Basic convolution network architecture

The network includes an input layer in the format of the tensor 50x50x1 The following are several convolutional and pooling layers. After that, the network unfolds in one fully connected layer, the outputs of which converge into one neuron, to which the activation function, the sigmoid, will be applied. At the output, we obtain the probability that the center point of the input fragment belongs to the "boundary point" class.

The Keras open source library was used to develop and train a convolutional neural network [START_REF] Keras | The python deep learning library[END_REF][START_REF] Chollet | Deep Learning with Python[END_REF][START_REF] Gulli | Deep learning with Keras: implement neural networks with Keras on Theano and TensorFlow[END_REF][START_REF] Vanderplas | Python Data Science Handbook: Essential Tools for Working with Data[END_REF].

The basic convolutional neural network was trained with the following parameters:

-10 epoch; error -binary cross-entropy; quality metric -accuracy (percentage of correct answers); optimization algorithm -RMSprop.

The accuracy on the reference data set provided by the base model is 90.8%. In order to improve the accuracy of predictions, a script was written that trains models on several configurations, and also checks the quality of the model on a test dataset.

To improve the accuracy of the predictions of the convolutional neural network, the following parameters were varied with respect to the base model:

increasing the number of layers: + 1 convolutional + 1 pooling; increasing of the number of filters: +32 in each layer; increasing the size of the filter up to 5*5; increasing the number of epochs up to 30; decreasing in the number of layers.

These modifications of the base convolutional neural network did not lead to an improvement in its performance -all models had the worst quality on the test sample (in the region of 88-90% accuracy).

The model of the convolutional neural network, which showed the best quality, was the base model. Its quality in the training sample is estimated at 90.8%, and in the test sample -at 83%. None of the other models were able to surpass this figure. Data on accuracy and epoch error are shown in Fig. 4 and5. 6 shows examples of images with neural network boundaries. As you can see from the images, not all the borders are closed. The boundary discontinuities are too large to be closed using morphological operations on binary masks; however, the use of the "watershed" algorithm [START_REF] Sonka | Image Processing, Analysis and Machine Vision[END_REF] will reduce the identification error of the boundary points.

Conclusion

In this work, a convolutional neural network was developed and tested to recognize boundaries on images of crushed ore stones. For the task of constructing a convolutional neural network model, two data samples were generated: training and test dataset. When building the model, the basic version of the convolutional neural network structure was implemented. In order to improve the quality of model recognition, a configuration of various models was devised with deviations from the basic architecture. An algorithm for training and searching for the best model by enumerating configurations was implemented.

In the course of the research, it was found that the basic model has the best quality for recognizing boundary points. It shows the accuracy of the predictions for the targeted class at 83%.

Based on the drawn borders on the test images, it can be concluded that the convolutional neural network is able to correctly identify the boundary points with a high probability. It rarely makes mistakes for cases when there is no boundary (false positive), but often makes mistakes when recognizing real boundary points (false negative). The boundary breaks are too large to be closed using morphological operations on binary masks, however, the use of the "watershed" algorithm will reduce the identification error for boundary points

Fig. 1 :

 1 Fig. 1: Examples of crushed ore images

Fig. 2 :

 2 Fig. 2: Image processing

Fig. 4 :

 4 Fig. 4: The dependence of the accuracy on the training and test datasets from the training epochs

Fig. 5 :

 5 Fig. 5: The dependence of the error on the training and test datasets from the training epochs

Fig. 6 :

 6 Fig. 6: Images of crushed ore particles with boundaries detected by a neural network


Nikolay Buldakov
email: n.buldakov@innopolis.ru

Timur Khalilev
email: t.khalilev@innopolis.ru

Salvatore Distefano
email: sdistefano@unime.it

Manuel Mazzara
email: m.mazzara@innopolis.ru

An Open Source Solution for Smart Contract-based Parking Management

This paper discusses an open-source solution for smart-parking in highly urbanized areas. We have conducted interviews with domain experts, defined user stories and proposed a system architecture with a case study. Our solution allows integration of independent owners of parking space into one unified system, that facilitates parking in a smart city. The adoption of such a system raises trust issues among the stakeholders involved in the management of the parking. In order to tackle such issues, we propose a smart contract-based solution encapsulating sensitive information, agreements and processes into transparent and distributed smart contracts.

Introduction

It has been estimated that, with the current trend, 60% of people will end up living in urban areas [START_REF] Mcgranahan | Urbanisation concepts and trends[END_REF]. The increasing pace of the urbanization process made the management of city services more challenging Among such services transportation has strategic importance since the increase of population leads to increased traffic congestion and pollution, which significantly impacts on the citizens' lives. Several approaches have been adopted to address these issues, and in 1970s some countries decided to widen the roads and create new ones. For example, in Hague, Netherlands, many canals were drained and covered for this purpose [START_REF]Mvrdv unveils plans to reopen the hague's forgotten canals[END_REF]. More modern approaches focus on the factors affecting congestion and operate on them. This trend has led to smart management of streetlights [START_REF] Sei | A traffic-aware street lighting scheme for smart cities using autonomous networked sensors[END_REF], and the introduction of payed parking lots and roundabouts. Several studies have also shown that searching for a free parking stall drastically affects the traffic as vehicles spend some time going around looking for parking [START_REF] Giuffrè | A novel architecture of parking management for smart cities[END_REF]. Smart parking solutions can, therefore, significantly improve traffic conditions.

There are several open issues and challenges on the current parking management. First of all, in every district, there are slots of unused land, owned either by private or public entities. Providing easy means of renting out such properties for parking can simplify the process of creating new parking lots. Moreover, collection and aggregation of information about the current occupancy of all parking lots can significantly simplify the process of finding a free stall, thus decreasing traffic congestion. Another significant issue is the trustworthiness of a potential parking system. With the current solutions on the market, such as [START_REF] Yang | Smart parking service based on wireless sensor networks[END_REF] sensitive information is stored in a centralised way, which makes it vulnerable and simplifies malicious intrusion. Finally, various parking providers need aggregation under one universal system, that will guarantee the unbiased treatment of all parking lots. Such strategy will allow potential seekers of parking lots to observe the entire situation in the city instead of seeing only partial information. This work aims at creating an open-source solution in order to tackle the aforementioned problems.

Problem Statement

Every city has governing authorities: city Hall, municipality and it can be divided up into districts with local councils. It can also be organized in terms of smart governance [START_REF] Meijer | Governing the smart city: a review of the literature on smart urban governance[END_REF]. We will further refer to these authorities as an Administrator. The Administrator is responsible for authorising processes in the city. There are also people and companies possessing pieces of land that are suitable for parking. We refer to them as Landlords. A landlord can be a juridical person or a natural person; it does not matter for the system. A landlord wants to provide their land for parking in order to profit from parking fees. Besides, there are entities called Tenants. A tenant is a company or a person who will to whom a landlord rents out a subset of their parking land-based on some conditions.

Figure1. Contracts' hierarchy

Now that all the roles are defined, one can observe the relations connection different roles in figure 1. In order to provide their land for parking, a landlord must first sign a contract with the administrator. There is always only one administrator for each area in the city. The process starting from a request to create such contract (from the landlord's side) up until its signing by both parties will be called landlord registration. This process involves checking whether the landlord is eligible for renting out their property, and negotiation on the details of the contract. Eventually, the signed contract contains such details as the tax which the landlord guarantees to pay, information about the registered land, duration of the contract and others. Both parties can further amend the contract, given that they are satisfied with the amendment. The landlord, in turn, can not only provide their land for parking but also they can rent it out to tenants. In this case, the income from parking will not go directly to the landlord, however, they receive guaranteed rent payments and, possibly, a percentage from each parking transaction. Similarly, another contract preserved the agreement between a tenant and a landlord. This contract describes all the details of the rent. Such details are the duration of the contract, the rent fee, the frequency of payments, the landlord's share in each parking transaction and, most importantly, the exact borders of the area rented to each tenant. Again, all these details can be amended later, given the consensus of both parties.

Assumptions about parking lot

There is a set of preconditions, which this study assumes parking lots to hold. First of all, the parking areas have to be divided up into a set of spots. We refer to these spots as parking stalls. This partition can be represented by road marking. Moreover, there has to be a tracking device which will make the parking lot fully observable. A particular example can be a camera with an IoT-powered box, produced by Park Smart [2] as described in their patent [START_REF] Smart | Allocating an area to a vehicle[END_REF]. This device has to run image processing algorithms in spot in order to tell at each moment which parking stalls are occupied (a particular implementation is provided in [START_REF] Acharya | Real-time image-based parking occupancy detection using deep learning[END_REF]) and what the plate numbers of the parked cars are. A visualisation of these assumptions can be found in Figure 2 A real example could be a mall with a big parking zone. Stalls can be partitioned among the businesses that are present in the mall. Big companies, like Ikea could rent the closest stalls in order to ease transportation of goods from the store to cars. Restaurants could want to offer reduced fares to their visitors for parking. There can also be stalls that are not rented by any company. In this case, a car parked there pays according to the pricing policy of the landlord, i.e. the mall.

Proposed solution

The proposed solution presented in this paper aims to tackle the problems described above by using blockchain smart contracts. It assumes a set of roles to be present is the city. One of them is a city hall, that will be responsible for the deployment of the system as Figure2. Example of the assumed parking lot well as setting several policies following the local legislation. Another role is a landlord who possesses a piece of land. A landlord can be a juridical person or a natural person, it does not matter for the system as long as their land satisfies the constraints describer in the Assumptions section. Such situations are common: a landlord does not want to maintain the land fully themselves and rents its parts out, in this case the proposed system allows a landlord to partition their land as they desire and set complex paying policies, that will ensure the agreed-upon conditions at the time of payment for parking. The last role is a driver interested in parking their car. They can observe free spots available at every parking lot and the pricing policy and choose the most suitable one. Payment is also covered conducted through the system, using a micro-payment channel, that makes it possible to enforce and guarantee the distribution of money among the landlords, the city hall and the tenants.

Related Work

By the time of writing, various smart parking systems exist in the literature, that focus on various aspects of parking. In principle, we can divide them into two groups: centralized solutions and decentralised solutions.

Centralized solutions

There is a garden variety of solutions present both in the market and research, which attempt to prove a framework to manage smart parking. However, the major drawback of most of them is their centralised nature. Many of them rely on a particular supreme entity, their "source of truth". In [START_REF] Khanna | Iot based smart parking system[END_REF] a parking system is proposed that relies on IoT devices and exchanges data by means of TCP/IP protocol. However, the application resides on only one server, that makes it vulnerable to issues with security, trustability and single point of failure.

Decentralized solutions

Other works propose architectures that utilise the blockchain solutions as their backbone. All centralised solutions share a common set of problems that make them undesirable for practical use. The most important of such issues is trustworthiness. All participants of such systems have to rely on a particular entity, that will possess the power of accessing, chaining and removing their data, with no guarantee at the time of signing an agreement or registering that the owner of the system will obey to the promised rules. Lack of transparency is another significant shortcoming. When the implementation is not exposed to the end-users, they cannot validate that a particular solution is guaranteed to function in accordance with their needs and that it does not have any back-doors. Finally, considering the ongoing competition Figure3. Overview of Integrated Smart Parking System, taken from [START_REF] Ahmed | A blockchain-based architecture for integrated smart parking systems[END_REF] on any market, including parking, a centralised solution can be unfair to some participants if the owner is biased towards some companies. In [START_REF] Ahmed | A blockchain-based architecture for integrated smart parking systems[END_REF] a system is proposed for incorporating blockchain into regular parking scenarios. This paper presents a layered architecture that standardizes the typical architecture of an integrated smart parking system. It also describes the major components of the system as well as provides an overview of possible work-flows of the solution. In this system, there are three major participants: parking service provider, blockchain network, and user. The network enjoys the standard blockchain characteristics: a consensus algorithm, a shared public ledger, running a local copy of the ledger at each parking area. The overview schema of the system can be seen in 3. The architecture in the described solution consists of four layers: application layer, network layer, transaction layer, and physical layer. This layout of technologies can be considered the current state of the art and is adapted in the solution, proposed in this thesis work. Finally, the authors of the paper describe two main workflows supported by their system: 1. Search and Request of a parking spot and 2. Parking Provider Operations in the system. Even though the paper describes a useful basic concept, it supports a minimal number of scenarios, and thus, one cannot consider it as realistic. Another blockchain-powered system is presented in [START_REF] Hassan Sabeela | Parkchain: A blockchain powered parking solution for smart cities[END_REF]. It aims to take into account the process of setting up the parking space for the land-owner. For this they a landlord has to go through government validated process and procedures such as Land Registry and Government mandate external system. The external control is conducted by presenting another entity, named Oracle. In addition to that, they tackle the problem of leasing lands to the so-called contractors by distributing non-fungible tokens among them for a particular period. These tokens are issued to the certified landlords by the government. The critical advantage of this solution is that it describes in great details peculiarities related to how governing authorities and lease of land can be integrated into a blockchain system. However, many processes are supposed to happen off-chain, which is a serious limitation for the true decentralisation of the system. [START_REF] Hu | Parking management: A blockchain-based privacy-preserving system[END_REF] presents registration, search, rent, payment modules built by the means of the BCOS smart contracts framework. The main novelty of this system is the use of one-time pad mechanism and a group-signature mechanism together with a union of privileged nodes in order to conceal the details of each transaction and thus preserve users' privacy while the privileged nodes can still access users' data. One-time padding means that instead of receiving a real address for each transaction, users, instead, receive a newly generated address each time. This way, the users' addresses are not exposed. A group signature mechanism allows signing a transaction on behalf of a group, which hides the mapping between transactions and users. Other concepts implemented in this system are relatively similar to the works mentioned above, so the privacy mechanisms are the main beneficial feature of the paper. Finally [START_REF] João | A blockchain and gamification approach for smart parking[END_REF] introduces a gamification approach that simplifies the process of finding a parking lot. It encourages users to take part in the reporting process, by using the data history in order to calculate which places are more likely to be empty and by providing a framework that does not assume or require any particular installation of infrastructure. In this system, the concept of mobile crowdsensing plays a pivotal role.In order to ensure the involvement of drivers, the system assigns individual points to each driver for their collaboration. Examples of such collaborations are the installation of a special beacon or reporting on the number of free parking spaces in the street. Pedestrians can also participate by reporting through a mobile app. These points can be exchanged for free parking minutes. The authors claim their approach to bring a variety of benefits including a faster search for parking (leading to lower CO2 emissions), easy deployment of the solution as it does not require much an existing infrastructure. Although their reasoning is valid, there is almost no information in the paper how the blockchain technology was incorporated.

Discussion

Although the works mentioned in this literature review present a variety of parking solutions, a significant limitation is in the fact that all of them lack flexibility for the end users. There is a variety of possible configurations of the system present, for example with a governing agency involved [START_REF] Hassan Sabeela | Parkchain: A blockchain powered parking solution for smart cities[END_REF] or without [START_REF] Ahmed | A blockchain-based architecture for integrated smart parking systems[END_REF]. However, none of them allows the community to choose what type of configuration they need. The same issue arises with the pricing policy. All papers consider some pricing policy present and even fluctuating depending on some factors as time and demand [START_REF] Ahmed | A blockchain-based architecture for integrated smart parking systems[END_REF]. However, the details are omitted of how exactly the pricing is organized as well as how shares are distributed among different entities in the system. Finally, the topic of leasing or renting out the land is not thoroughly defined, in particular, how exactly it can be done through the system. In [START_REF] Hassan Sabeela | Parkchain: A blockchain powered parking solution for smart cities[END_REF] a token system is proposed but the details of how exactly the partitioning of a land will be tackled in the system are not presented.

System Design

The objective of this work is to take into account drawbacks of the current centralised parking solutions, as well as limitations of the decentralised parking systems and to design and build a system that would address those issues. The system will utilise smart contracts and take into consideration some realistic requirements gathered by interviewing people from the industry.

Interviewing Industry representatives

Any proper system-development commences with gathering important requirements of the system. Furthermore, as [START_REF] Joseph | Techniques for requirements elicitation[END_REF] states "one might use questionnaires or interviews to explore what problems members see as most important, how members place themselves in various classification schemes, etc." Thus, an interview has been conducted with a representative of Park Smart [2]. Park Smart is a smart parking solution company founded in Italy, Messina in 2014 and its main aim is to implement a software-based technology able to analyse, in real-time, the availability of space in in-street parking. The company has already been in the field for a few years. Therefore, was valuable to question them about their experience and to learn what are the main requirements for a parking system. The interview has shown some essential aspects of the modern smart parking system and it has also revealed some common shortcomings of the existing system. For instance, if a company wants to use this solution for paid parking, they can provide their end point to Park Smart in order to receive money through the system. This approach has inspired the idea of service providers in our system. Moreover, the interviewee has confirmed our concern about the centralisation of current systems. Park Smart itself has a patent about blockchain architecture for their system, however, it has not been implemented yet. Besides, the importance of flexible pricing policies has been highlighted. Companies have different rates at a different time of the day, therefore, this part of functionally is to be flexible. Finally, we found out what particular information about users and processes is needed for such a system, and this has affected our decisions of what to store in the proposed solution.

Figure4. System Overview

Product backlog

In order to comprehend the needs of various user roles in the system, user stories have been gathered. The roles that we considered are the following: Administrator, Landlord, Tenant, Driver, and Service Provider. The user stories have revealed a particular set of features that every role needed. Here we extract the key functionality from the user stories. First of all, both driver and parking providers (landlords and tenants) require a safe, trustworthy way of conducting payments in such a way that both parties are guaranteed that the amount of funds transferred is equivalent to the provided service. Besides, landlords and tenants want to ensure that both parties respect the renting contracts they make among them and that such contracts can be extended or amended over time. Parking providers also want the system to postulate equal treatment for all parking lots so that there are no privileged ones, promoted by that system. Finally, the administrative authority requires to have privileged over the system (bounded by conditions of contracts made with other parties). In total, the backlog is constituted by more than 30 user stories, which were considered during the design and implementation phases.

System Design Overview

There are several participants in the system: landlord, tenant, driver or car, IoT box installed in each parking system, administrator and as a governing authority. The parking system consists of thin clients (such as a mobile or a web app), and each participant can access their part of functionality through the thin client. Every thin client is connected to a local EVM (Etherium Virtual Machine) node, which in turn is connected to the rest of the Etherium network. The local node has an instance of the ledger, shared by all nodes, and also hosts smart contracts. Whenever a participant wants to perform an action (e.g. initiate parking or update number of free parking sports), the thin client tells the EVM to invoke a corresponding method of some smart contract. This action is performed in the form of a transaction on the blockchain. The blockchain network contains a public ledger and updates the public ledger with the valid transactions only. A consensus mechanism is used to verify the transactions. Once the new transaction is verified, the public ledger is updated, and the local copies of the ledger in each node are synchronised and all participants can observe the new state of the parking system. This overview is visualised in 4

Smart contracts

Smart contracts are the back-end part of the system. The logic is distributed among several contracts, which correspond to logical components of the system. Each contract encapsulates its sensitive data and controls access to its functions. This way, only authorised entities can perform actions in the system, even though the contracts are publicly exposed. Actors of the system deploy some of the contracts, other contracts are deployed automatically in existing contracts. The decision of whether a contract is deployed from the outside of the system or within contracts depends on two questions:

1. Is the nature of the contract static or dynamic? 2. Should the system validate and control the deployment process of a contract?

The nature of a contract matters because some contracts are deployed once and remain active in the system for a long time, whereas others are needed only for a short amount of time, and after their expiration, they cannot be used inside the system anymore. An example of a static contract could be the Parking System contract, which is deployed by the authorities and the life cycle of this contract defines the life cycle of the system itself. On the other hand, an example of a contract of a more dynamic nature could be a Payment Channel. Whenever a new parking process commences, the system automatically generates a payment channel. Such a contract has a short lifetime and cannot be reused. Thus the burden of its creation lies upon the shoulders of a static contract -Parking Provider. The latter question tackles the problem of validation. Contracts can be inherited, and their behaviour can be changed by other parties. For example, the Parking Lot contract can be modified to surpass the tax obligation. That is why one requests the system to deploy such a contract. The system verifies all information related to the contract and only after that deploys it. For other contracts, on the contrary, extensions are allowed. For instance, Payment Policy defines a set of methods to be implemented to calculate the price of particular parking, however, it is up to a parking provider how exactly the price will be calculated. Thus, a parking provider is entitled to extend and deploy their payment policy and supply the address of this policy to the system.

Parking System

Parking System is the first contract to be deployed to launch the system. It is deployed by an administrative authority (e.g. a city hall) and it implements the main managing functionality of the system. The parking system contract is responsible for the registration of new parking lots and cars as well as for storing addresses of all other entities in the system. Whenever some request cannot be fulfilled automatically by the contract, it saves the request and pends administration's approval. Moreover, this contact provides a means of control and management of the whole system. Thus, the system cannot exists without this contract.

Parking Provider

Parking provider is an abstract contract that cannot be used on its own but should be extended in order to be used. It implements the logic of the parking process and stores information about what parking stalls it possesses and what cars are parked at the stalls. In other words, whenever a car wants to park, the code of this contract is used. In order to park a car sends funds to this contract. It also specifies a stall number and till what time it wants to be parked. The contract calculates the price, checks if the funds sent are sufficient and whether a parking stall is free and after that creates a payment channel. Optionally parking provider can also have a set a service providers, in this case a car can specify which service provider it is using and a fraction of the payments will go to the service provider.

Car

This contract preserves general information about a car. This information includes its plate number, account address of its owner and the rating of the car in the system. In addition to that, it stores information about parking. That includes whether the car is parked now or not, the address of the payment channel, parking history. If one needs some information about a car, this is the contract to address.

Parking Lot

Parking lot extends Parking Provider contract and is deployed by the parking system contracts at a request of a landlord and with approval of the administrator. This contract adds functionality to partition the parking lot among several tenants. In order to do so, a tenant creates a request to this contract. If the landlord approves the request, the contract creates a renting contract between the landlord and the tenant. It also contains general information about the parking lot, such as its rating, address and so on.

Tenant

Tenant also extends Parking Provider contract. Unlike Parking Lot contract, this contract does not need permission from the system to be deployed as it interacts only with a parking lot. A tenant can set its payment policy and it also stores the address of its contract with a parking lot.

Service Provider

Conceptually a service provider is a third-party entity that collaborates with a parking provider in order to place information about the parking provider's stall on their platform. Thus, the contract only facilitates the interaction between a service provider and a parking provider. It contains information about a service provider and about parking provider with whom it collaborates.

Renting Contract

Renting contract implements a relationship between a parking lot and a tenant in such a way that both parties are guaranteed that their agreement will be respected in the system. The contract is deployed when the parking lot contract approves registration of a new tenant. After that, the tenant reviews the contract and if conditions are satisfactory, the renting process begins. The contract also contains logic for penalties in case of delayed payment. Finally, it supports the introduction of amendments from both parties. In the case of mutual agreement, such amendments can modify the behaviour of the contract.

Payment Channel

Payment channel implements the logic for micropayments between two parties, in such a way that both parties are guaranteed to receive the promised funds. One party opens the contract and sends funds to it. After that, the funds are locked in the contract, and neither of the parties can access them. Micropayments are conducted off-chain, therefore, they are not part of this contract. Once the payment process is completed, the receiving party sends the last encrypted message to the contract, and the contract uses encryption algorithms to verify that the party is entitled to receive the funds. If that is the case, funds are sent to the receiver's address. The detailed description of the principles behind this contract can be found in 3

Payment Policy

Payment policy is a protocol that defines two methods: get payment rate at a particular time and get a total price for parking given the start and the end time. It is up to parking providers to define their parking policies, depending on their business goals. A particular implementation of this protocol is provided. It implements a policy that can have a specific rate depending on an hour and a day of the week.

Parking system front-end

The front-end part of the parking system is a distributed application in the form of web, mobile or embedded software installed on mobile phones and computers of the Administrator, landlords, tenants and drivers as well as in IoT boxes at parking lots. In future they will be referred to as think clients. Every thin client provides a user interface or an API for interaction with the system. User interfaces are used by landlords, administrator, tenants and drivers. The API is used by the IoT box or a smart car. The front-end part is responsible for translating users' actions into requests to the smart contracts.

Communication between the smart contracts and the parking system

In order for the front-end distributed application to communicate with the EVM, there has to be a specific data-interchange format. This format is called JSON-RPC [START_REF]Json-rpc 2.0 specification[END_REF]. It is utilised through a JavaScript library called Web3.js 1 , which allows us to interact with a local or remote Ethereum node using a HTTP or IPC connection [4]. As depicted in Figure Figure5. Communication with the blockchain

Micro-payment channel

Whenever a car gets parked at a parking lot, there is a mutual agreement between the parking lot and the car: the car receives a service and transfers money for parking. In a traditional system, the payment is conducted in advance for a particular period, [START_REF] Litman | Parking pricing implementation guidelines how more efficient parking pricing can help solve parking and traffic problems, increase revenue, and achieve other planning objectives[END_REF]. Such system lacks trustworthiness, as a car has to blindly trust the parking provider, that the service will be provided sufficiently and will not be interrupted earlier, the parking provider, in turn, has to ensure that the car is not parked for longer than the paid period, this requires additional control that brings an additional cost. Finally, parking is not a discrete process, unlike the pricing policy in traditional parking systems, which results in drivers oftentimes paying more than they should. This problem can be solved by implementing a micro-payment channel through a smart contract and direct signed messages. The high-level picture of such payment includes three steps:

1. Driver deploys a contract with locked funds of some amount that exceeds any possible parking period. 2. Driver emits messages directly to the service provider. The messages are the "microtransactions" containing how the amount is transferred. The parking lot can check the validity of the messages as they are signed by car. 3. After the parking process is over, the service provider can use the last message to retrieve the claimed amount of funds from the contract. The remained of the locked funds are sent back to the car. It is essential to mention that in this scenario only steps 1 and 3 happen on the blockchain and the most intense process of micro-payments is conducted off-chain through a peer-to-peer communication [START_REF]The peerjs library documentation[END_REF]. Thus, the parties do not have to conduct costly blockchain transactions (gas in Etherium terminology [START_REF] Dannen | Introducing Ethereum and Solidity[END_REF]) for each payment. Only two transactions are required: to deploy the contract (by the car) and to claim the end of the payment period (by the parking lot). Moreover, the transaction fee will be paid by the service provider, thus removing any additional fees from the car. This process is visualised in 6 4 Conclusions A significant amount of research has been conducted on smart parking. In this paper, we have examined some of the recent work related to this topic and propose a solution. Interviews have been conducted with domain experts, user stories defined and a system architecture has been proposed with a case study. Our solution allows independent owners of parking space to be integrated into one unified system, that facilitates the parking situation in a smart city. The utilization of such a system raises the issues of trust and transparency among several actors of the parking process. In order to tackle those, we propose a smart contract-based solution, that brings in trust by encapsulating sensitive relations and processes into transparent and distributed smart contracts. From the architecture point of view services and, in particular, microservices [START_REF] Dragoni | Microservices: yesterday, today, and tomorrow[END_REF][START_REF] Mazzara | Size matters: Microservices research and applications[END_REF][START_REF] Bucchiarone | Microservices, Science and Engineering[END_REF] and their composition, orchestration [START_REF] Mazzara | Towards Abstractions for Web Services Composition[END_REF][START_REF] Mazzara | A Case Study of Web Services Orchestration[END_REF], reconfiguration [START_REF] Mazzara | Design, modelling and analysis of a workflow reconfiguration[END_REF] and recovery [START_REF] Dragoni | A formal semantics for the ws-bpel recovery framework[END_REF] have not been discussed. All these are open issues that need to be investigated in future.

Figure6.

  Figure6. Sequence diagram of micro-payments over blockchain

Every front-end module of the distributed system communicates mostly with their own smart contract and this contract, in turn, is responsible for the interaction with the Parking System module and other modules.1 https://github.com/ethereum/web3.js/