Zhen Hong

Zhiping Wang

Sihao Deng

Yicha Zhang#

Alain Bernard

Physical Deposition Profile Based Toolpath Generation and Optimization for Additive Volume Building in Hybrid Additive Manufacturing

Keywords: toolpath optimization, profile-based sweep, Hybrid Additive Manufacturing (HAM)

In hybrid additive manufacturing (HAM), toolpaths affect the volume building and removing during the sequential or iterative hybrid processing since they control the deposition nozzle or cutting tools. In sequential hybrid additive manufacturing, toolpaths for additive manufacturing module define the volume directly determines of the shape accuracy and volume building time. In this paper, we report a new toolpath generation and optimization method for a developing cold spraying -based HAM process's additive processing module. This method adopts a valid physical deposition profile to set scanning parameters and then applies an evolutionary optimization algorithm to minimize the total scanning length for building a set of ordered disconnected volumes on a predefined base. The propose method is illustrated by a complex tree shape model and validated by three selected numerical examples. It has potential to help save spraying raw materials and time as well as improve shape accuracy.

Introduction

During the past more than three decades, additive manufacturing (AM) becomes more and more essential for functional manufacturing as the process and material development [START_REF] Wohlers | Wohlers Report 2020: 3D Printing and Additive Manufacturing State of the Industry[END_REF], because of its capacity to manufacture parts with complex surface and internal geometries by adding layers of materials without the use of tooling or fixtures enables [START_REF] Zhang | Bio-inspired generative design for support structure generation and optimization in Additive Manufacturing (AM)[END_REF], as well as the freedom to design, mass personalization, less shipping parts and warehouse storage, and less waste and energy consumption [START_REF] Thompson | Design for Additive Manufacturing: Trends, opportunities, 1181 considerations, and constraints[END_REF][4] [START_REF] Gao | The status, challenges, and future of additive manufacturing in engineering[END_REF] [START_REF] Gibson | Additive manufacturing technologies[END_REF]. Even though AM has many advantages, compared with traditional processing technologies, limitations still exist, such as poorer dimensional accuracy and surface quality [START_REF] Vayre | Metallic additive manufacturing: state-ofthe-art review and prospects[END_REF] [START_REF] Paris | Process planning for combined additive and subtractive manufacturing technologies in a remanufacturing context[END_REF], limited materials and relatively long printing time for some applications [START_REF] Ramaswami | Process planning for shape deposition manufacturing[END_REF], especially for metallic AM processes. Therefore, only AM being employed, it is probably costly and not easy to guarantee high accuracy and feasibility. On the contrary, traditional manufacturing processes like CNC, have many advantages, such as high speed and high quality of finish surface, which can greatly compensate the shortcomings of AM [START_REF] Ramaswami | Process planning for shape deposition manufacturing[END_REF]. Therefore, the combination of additive and traditional manufacturing processes is considered as a promising solution to compensate the limitations of both AM and traditional processes by taking advantage of the strength of both AM and traditional processes [START_REF] Flynn | Hybrid additive and subtractive machine tools-Research and industrial developments[END_REF] [START_REF] Karunakaran | Low cost integration of additive and subtractive processes for hybrid layered manufacturing[END_REF]. As a consequence, the combination brings new opportunities for various applications [START_REF] Zhu | A review of hybrid manufacturing processes-state of the art and future perspectives[END_REF] and is increasingly employed for producing or remanufacturing functional parts [START_REF] Paris | Process planning for combined additive and subtractive manufacturing technologies in a remanufacturing context[END_REF] [START_REF] Ren | Part repairing using a hybrid manufacturing system[END_REF][14] [START_REF] Paris | Extracting features for manufacture of parts from existing components based on combining additive and subtractive technologies[END_REF]. For the existing research of hybrid additive manufacturing, there are sequential processes and iterative processes [START_REF] Patterson | Manufacturability constraint formulation for design under hybrid additive-subtractive manufacturing[END_REF]. In this paper, The HAM is a sequential process, specifically, cold spray with CNC.

Although the hybridization idea of the two types of processes seems simple, the real operation for process combination becomes more difficult since both of the existing constraints of AM and NAM processes are introduced and couple with each other. Therefore, the process planning for HAM is critical for the implementation of process combination. Some researchers noticed the importance of this and had already conducted a few investigations as reviewed in [START_REF] Nassehi | Using formal methods to model hybrid manufacturing processes[END_REF] . However, there are still a plenty of problems not well solved or even touched. such as selection on candidate processes for HAM, manufacturability analysis for HAM, estimate the process from zero or an existing volume, the generation of the existing volume, sequence planning, toolpath planning, etc.

This research focuses on the question of toolpath generation in the AM module for multiaxis HAM, based on Cold Spray (CS) with CNC. For the existing research of toolpath planning for AM, there are some limitations such as, no consideration of the real deposition profile, less study on the step length of declination angles, using rastering/zigzag, etc. To solve this problem, this paper introduces a geometric computational method to generate an optimal toolpath angle for each layer, with the consideration of toolpath length, but it is illustrated mainly for AM.

The remained structure of this article is as follows: section 2 is about the existing researches of tool path planning; in section 3, the proposed method is implemented and the case study is operated in the following section. The last section is about the conclusions of this research and the perspective of future work.

Related work

This research focuses on process planning for sequential multi-axis HAM and the CSHAM (Cold Spray-based Hybrid Additive Manufacturing) platform is in development at UTBM, which is a modular HAM robotic platform, where robots are used as connections to link different existing processing modules/machines. Therefore, there is no need to integrate and modify the existing machines, and it is more flexible, reconfigurable, sustainable, etc. In the CSAM platform, the CS gun is fixed, and the robot catches the substrate to fix the initial volume (an existing volume to deposit material onto and become one part of the final component). In this article we focus on the toolpath for AM module in CSHAM, which similar with other types of AM, but a little different, because the CS gun cannot stop. Therefore, the length of the toolpath is important in this research.

Since toolpath planning is very important for AM, there exist much research as mentioned above. Moreover, for multi-axis AM process, the toolpath can be 3D curve paths [START_REF] Xie | A potential field based multi-axis printing path generation algorithm[END_REF]. However, most HAM systems still use planar scanning in the AM processes. And toolpath planning for AM can be divided into two components: interior and exterior path planning and varies due to different AM technologies [START_REF] Kulkarni | A review of process planning techniques in layered manufacturing[END_REF]. In addition, the process of filling in the interior of the layer is accomplished by means of path planning, while the external is usually by removing materials [START_REF] Kulkarni | A review of process planning techniques in layered manufacturing[END_REF]. Various types of toolpath patterns from milling can be introduced into AM, such as rastering similar with zigzag, contours, spirals, and some other filling patterns [START_REF] Jin | Optimization of tool-path generation for material extrusion-based additive manufacturing technology[END_REF]. And the popular types are as follows in Figure 1. One crucial issue to be addressed relates to offset problems along the trajectories. The problems of offset [START_REF] Ren | Adaptive deposition coverage toolpath planning for metal deposition process[END_REF] are divided into three types: void type I occurs when the area to be filled is too large for a single pass, but not large enough for another parallel offset path; void type II occurs when corner geometry has too sharp of an angle, depending on specific process parameters such as laser spot size; void type III will occur if the offsetting algorithm generates more than one loop allowing a void between the separated loops [START_REF] Ren | Adaptive deposition coverage toolpath planning for metal deposition process[END_REF]. The spiral path has similar void with offset method and a new spiral path is generated that has no sharp corners. So one method to improve the problem is proposed and the brief procedures are as follows [START_REF] Kao | Optimal motion planning for deposition in layered manufacturing[END_REF]: (1) Obtain MAT (medial axis transform) of original 2D cross-sections, (2) Re-parameterize the skeleton by arc length, (3) Solve the above optimization problem, (4) Compute spiral paths from the medial axis and the optimized radius function. The zigzag path is also very generally used. Liou et al. developed a hybrid manufacturing process with coverage toolpath planning, zigzag with interlaced direction [START_REF] Ren | Part repairing using a hybrid manufacturing system[END_REF].

For a continuous 5-axis laser cladding process, the experiments to study different toolpath strategies and to arrive at an optimal toolpath consider quantitative criteria such as the deposition rate, the wetting angle and the height and width clad tracks [START_REF] Calleja | Improvement of strategies and parameters for multi-axis laser cladding operations[END_REF]. A configuration space approach to enable toolpath planning in a full three-dimensional space allows movements beyond planar slices [START_REF] Micali | Fully three-dimensional toolpath generation for pointbased additive manufacturing systems[END_REF]. The researchers in [START_REF] Micali | Fully three-dimensional toolpath generation for pointbased additive manufacturing systems[END_REF] change to the 2.5D paradigm by using a configuration space approach to enable toolpath planning in a full three-dimensional space, allowing movements beyond planar slices in the point-based AM systems which have many features in common with CNC milling machines. Moreover, medial axis transformation was used for adaptive path planning of wire-feed additive manufacturing [START_REF] Ding | Adaptive path planning for wirefeed additive manufacturing using medial axis transformation[END_REF].

To reduce build time, a concurrent toolpath planning algorithm generates collision-free multi-toolpaths to control the tools that deposit materials concurrently [START_REF] Choi | A topological hierarchy-based approach to toolpath planning for multi-material layered manufacturing[END_REF]. A mixed and adaptive toolpath generation algorithm has been then developed, aiming to optimize both the surface quality and fabrication efficiency in AM [START_REF] Jin | Adaptive tool-path generation of rapid prototyping for complex product models[END_REF]. For further improvement on fabrication quality, a toolpath adjustment is employed on the original toolpaths [START_REF] Jin | An adaptive tool path generation for fused deposition modeling[END_REF]. A mixed and adaptive toolpath generation algorithm is proposed to generate contour toolpaths for the boundary of each layer to make sure the surface quality, and zigzag toolpaths for the internal area of the layer to reduce build time. Moreover, the best slope degree of zigzag toolpaths is selected to further minimize the build time [START_REF] Jin | Adaptive tool-path generation of rapid prototyping for complex product models[END_REF]. Similarly, another research is also on the inclinations with very few angles [START_REF] Jin | Optimization of tool-path generation for material extrusion-based additive manufacturing technology[END_REF]. Therefore, there are limitations for the step length of scanning angles. In conclusion, there are still some limitations of toolpath planning, illustrated in table 1, and specially, the existing toolpath generation method did not consider many slope angles for optimization and real physical deposition profile. Moreover, there is no consideration of toolpath configuration for each layer (scanning type, angle, speed, energy, etc.). So, it is necessary to propose a method for toolpath generation and optimization to solve the above-mentioned limitations.

Given the limitations of the existing toolpath planning for AM. In our research, a potential method is proposed and the toolpath generation combines different toolpath types, the contour and rastering in this paper, and the rastering angles are optimized considering the total length of toolpath. The details of this methods are descripted in the next section.

Methodology

The global introduction of the proposed method

From the existing methods in the literature mentioned in section 2 for toolpath generation, for planar toolpath, combining different toolpath types can lead to good quality with less fabrication time and the proposed method is illustrated in Figure 2. From the existing methods as abovementioned, we can see that the limitation of existing methods for toolpath planning. In this research, only contour (for the two passes outside) and rastering (inside) are employed and the total toolpath length is optimized by varying the rastering angles with a small step length, 0.1 degree, by Particle Swarm Optimization algorithm (PSO).

The introduction of the physical profile of CS

In this research, for demonstration, we take the cold-spay-based HAM process for demonstration. The toolpath generation is based on coating profile proposed by Hongjian Wu et al. [START_REF] Wu | A new approach to simulate coating thickness in cold spray[END_REF]. The deposition is a three-dimensional geometric model based on Gaussian Distribution as well as the 2D cross-section profile, shown in Figure 3.

(1)

(2)

Figure 3 -The schematic of single coating profile model and different kind of overlaps on various surfaces [START_REF] Wu | A new approach to simulate coating thickness in cold spray[END_REF].

Figure 4 -The Gaussian distribution in GH.

In Figure 3 (1), it shows the schematic of single coating profile model on X-Y plane (red line) and X1-Y1 plane (blue line). θ and β are the spray angle on X-Y plane and X1-Y1 plane respectively. a is the angle between Z axis and Z1 axis. ψ is the deflection angle (the angle between Z axis and ab line, as well as AB line). γ is the angle between ab line and AB line. Figure 3 (2) (a) shows discrete single coating profile with overlaps, (b) continuous single coating profile on a flat surface, (c) continuous single coating profile on a curved surface, (d) continuous single coating profile on a complex surface. The Gaussian distribution profile [START_REF] Wu | Stable layerbuilding strategy to enhance cold-spray-based additive manufacturing[END_REF] is generated in GH (Grasshopper) as in Figure 4. The section of 2µ is used as a reference to define the layer thickness and hatching space.

The PSO optimization algorithm

Since GA (Genetic Algorithm) is very slow for iterations, the Particle Swarm Optimization algorithm (PSO) is adopted for searching optimal initial volume. The flow chart of PSO is illustrated in Figure 5. The PSO algorithm is a sub-field of Computational Intelligence. It belongs to swarm intelligence and collective intelligence and has both ties with artificial life and evolutionary computation. PSO is a type of biological system inspired by bird flocking and fish schooling. Its simulation was motivated by the need to model 'human social behavior' and the collective behaviors of individuals interacting with each other and their environment from the optimization process [START_REF] Kennedy | Particle swarm optimization[END_REF]. One plugin called Silvereye is introduced by visual programming in Grasshopper for Rhino3D modeling environment [START_REF] Cichocka | SILVEREYE-The implementation of particle swarm optimization algorithm in a design optimization tool[END_REF].

The slicing process is operated along the skeleton (the medial axis of the CAD model) direction evenly. The sliced layers with a fixed thickness referred from the experimental results of cold spray, the Gaussian distribution [START_REF] Wu | A new approach to simulate coating thickness in cold spray[END_REF]. The layers will be filled by the combined toolpath, i.e., contour with rastering, and the rastering with different angles inside. The whole toolpath length of one subpart is adopted as the objective to optimize the angle.

The idea is to use the result of adopted experimental deposition as cross-section profile to sweep along the generated toolpath to form 3D volume for the AM processing. For each layer, the process starts from outside to inside and the first two passes are contour trajectories to guarantee the accuracy. The objective is to minimize the length of the total toolpaths. The raster angles are optimized for each layer of every subpart which need to be built by adding materials and the step length of 0.1 degree for rastering is chosen based on the limitation of robot move precision. The following section introduces a PSO implementation for toolpath length optimization. For the encoding, each layer is one gene, so one chromosome is shown in Table 2. In the optimization process, the objective function is the total toolpath length shown in equation ( 1):

Min: 𝐿𝐿 = ∑ 𝑙𝑙 𝑖𝑖 𝛼𝛼 𝑗𝑗 𝑛𝑛 𝑖𝑖=1 (1) 𝛼𝛼 ∈ [0°, 180°)
where, 𝐿𝐿 is the total length of all toolpaths; 𝛼𝛼 is the rastering angle and 𝑙𝑙 𝑖𝑖 𝛼𝛼 𝑗𝑗 is ith layer's toolpath length with a rastering filling angle of 𝛼𝛼 𝑗𝑗 .

The illustrative example

To illustrate the method, a tree structure CAD model is employed, shown in Figure 6 (a), the volume (called the initial volume) in Figure 6 (c) is obtained by traditional processes, and the remaining volumes that need to be manufactured by depositing materials onto the initial volume are shown in Figure 6 (d), which is decomposed into different subparts (the decomposition process is out the scope of this paper), based on the skeleton of the tree model, shown in Figure 6 For the tree model, one subpart is chosen for demonstration, illustrated in Figure 8 (a). After the calculation of 1000 iterations, the corresponding shortest length of this subpart of tree model for each iteration is shown in Figure 7. One layer is selected to show the details of toolpath, shown in Figure 8. (b), (c). Since the layer with the same cross-section, the angles are the same (the white cylinder), shown in Figure 8. (b). All of the subparts with no collisions (the collision test is out of the scope of this article) have obtained their corresponding optimal toolpath by optimizing the rastering angles. The final result for the whole tree is illustrated in Figure 9 (a) with the details of local toolpath of one selected subpart in Figure 9 (b),(c).

In conclusion, in this research, the method has been proposed to improve toolpath planning and it is implemented with one complex tree model. In the following section, three case studies are operated to show the application of the proposed method.

Case study

Three examples are adopted at different complexity levels to test the proposed method. The first model is simple and the second one is selected from a published paper [START_REF] Lynch | Design and topology/shape structural optimisation for additively manufactured cold sprayed components: This paper presents an additive manufactured cold spray component which is shape optimised to achieve 60% reduction in stress and 20% reduction in weight[END_REF] ,which is designed for CS process. The third one is a part of the plane, which is complex and challenging to manufacture.

Case 1

The first case is a simple model shown in Figure 10 (a), and the grey part of Figure 10 (c) is the initial volume of case 1, which will be manufactured by traditional process. The green volumes are the remaining volumes that will be obtained by CS, and these remaining volumes will be decomposed into subparts according to the skeleton of case 1, but the details are beyond the scope of this paper. The evolutionary optimization algorithm PSO is adopted the same as for the tree model, and the calculation is also operated in the Silvereye plugin. The parameters are set the same as for the tree model, except the iteration number is 600. Because the cross-sections are even for the subparts, these angles are assumed the same for all layers of the whole subpart, shown in Figure 12. For all the remaining subparts, the process is similar, and the optimal toolpath for all the subparts is shown in Figure 13.

Case 2

The second model is from the existing research, a bracket manufactured with a cold spray process [START_REF] Lynch | Design and topology/shape structural optimisation for additively manufactured cold sprayed components: This paper presents an additive manufactured cold spray component which is shape optimised to achieve 60% reduction in stress and 20% reduction in weight[END_REF] and its CAD model is shown in Figure 14 (a). The whole model is built from scratch in their method, which needs an extensive support structure and causes many wasted materials. In our method, the process starts from an existing volume, called the initial volume. The initial volume is shown in Figure 14 One subpart of case 2 is chosen, and one of its layers is selected to show the details of optimal result, illustrated in Figure 15. Moreover, in this case, three green subparts, shown in Figure 16 (a), have collisions. Therefore, these three subparts are not considered for optimizing the toolpath, so only other subparts are manufactured by our method. The optimal toolpath of all of these subparts is illustrated in Figure 16 (b).

Case 3

The third case shown in Figure 17 is more complex than the previous two cases. And its CAD model is shown in Figure 17 (

Conclusions and Perspectives

In this research, a new method is improved to optimize toolpath planning considering the rastering with a small step length, 0.1 degree, for each layer. This method uses combined toolpath types, i.e., the combination of different toolpath types, and the boundary of each layer is contour, while the rastering is used to fill the inside area. The whole toolpath length is considered as a main criterion to find the optimized rastering angles for each layer in our research.

However, this toolpath planning method only considers planar slicing perpendicular to the skeleton branches. In addition, since the slicing process greatly influence the toolpath planning, and in our research, the slicing is multi-direction based on the skeleton (medial axis) of the CAD model, but uniform and planar. Therefore, nonplanar layers will be taken into account in the future for multi-axis process. Furthermore, we do not consider the complexity and sub-regions of each layer, so some research needs to be operated on both complex and too large cross-sections. Moreover, for large cross sections, the decomposition of cross-sections may be necessary to use more than one cutting tools or deposition nozzles in parallel to save time. It is also essential to consider the collision and iteration with traditional process like CNC/laser cutting (SM process).

Figure 1 -

 1 Figure 1 -Typical trajectories: rastering, spiral, offset, and combined type.

Figure 2 -

 2 Figure 2 -The proposed method for toolpath optimization.

Figure 5 -

 5 Figure 5 -The basic steps of PSO.

  (b).

Figure 6 -

 6 Figure 6 -(a). The tree model; (b). The skeleton of the tree; (c). The initial volume; (d). The remaining volumes (except the initial volume in grey).

Figure 7 -Figure 8 -Figure 9 -

 789 Figure 7 -The shortest toolpath length of each iteration.

Figure 10 -

 10 Figure 10 -(a). The CAD model of Case 1; (b). The skeleton of case 1; (c). The initial volume (in grey) and remaining volumes (in green).

Figure 11 -

 11 Figure 11 -The shortest toolpath length of each iteration of the selected subpart in case 1.

Figure 12 -

 12 Figure 12 -(a). The toolpath of one subpart; (b). The details of one layer of the selected subpart.

Figure 13 -

 13 Figure 13 -The toolpath of all the subparts.

Figure 14 -

 14 Figure 14 -(a). The CAD model of case 2; (b). The initial volume; (c). The remaining volumes to deposit material onto the initial volume.

Figure 15 -Figure 16 -

 1516 Figure 15 -The toolpath of one subpart with the details of one of its layers.

  a), and the initial volume is in Figure 17 (b), as well as the remaining volumes are in Figure 17 (c).

Figure 17 -

 17 Figure 17 -(a). The CAD model of case 3; (b). The initial volume; (c). The remaining volumes to deposit material onto the initial volume.

Figure 18 -

 18 Figure 18 -One subpart and one of its layers.

Figure 19 -

 19 Figure 19 -(a). The toolpath of all subparts which do not have collisions in case 3; (b). The subparts that have collisions (in red)

Table 1

 1 The limitations of existing method on toolpath planning.

	The method	The limitations	Ref.
	Contour	Three types of voids	[21]
	spiral path	Spiral path has similar voids with offset method	[22]
	Contour and zigzag	Only 6 different angles	[28]
	Contour and zigzag	Only 8 different angles	[30]

Table 2 .

 2 The encoding of different layers of one subpart.

	Layer	1	2	3	4	5	6	7	....	...	n
	Angle	𝛼𝛼 1	𝛼𝛼 2	𝛼𝛼 3	𝛼𝛼 4	𝛼𝛼 5	𝛼𝛼 6	𝛼𝛼 7	....	...	𝛼𝛼 𝑛𝑛

Table 2 .

 2 The parameters set in Silvereye.

	Parameter	Swarm size	Iteration	Max. Velocity
	Value	20	1000	0.2

Solid Freeform Fabrication 2021: Proceedings of the 32nd Annual International Solid Freeform Fabrication Symposium -An Additive Manufacturing Conference


Davaadorj Battulga
email: davaadorj.battulga@u-hopper.com

Mozhdeh Farhadi
email: mozhdeh.farhadi@u-hopper.com

Mulugeta Ayalew Tamiru
email: mulugeta.tamiru@elastisys.com

Li Wu
email: li.wu@elastisys.com

Guillaume Pierre
email: guillaume.pierre@irisa.fr

LivingFog: Leveraging fog computing and LoRaWAN technologies for smart marina management (experience paper)

Keywords: Fog computing, LoRaWAN, Kubernetes

In recent years, fog computing has emerged as a paradigm that brings computing, storage and networking resources closer to end users and devices at the edge of the network. One of the use cases for fog computing is IoT, where a large amount of data is generated by sensors that need to be pre-processed in place before the results are sent to the cloud for further processing and long-term storage. However, actual fog deployments are at their infancy. In this paper, we present the smart-marina project at La Marina de Valencia in which the LivingFog fog computing platform integrating opensource software and LoRaWAN technologies were used to process data collected from several sensors. We show the benefits of the platform in terms of latency reduction and bandwidth saving. Moreover, the platform has been used by particpants of the "Hack the fog" hackathon to deploy applications to test different innovative ideas on using the sensor data.

I. INTRODUCTION

The Internet of Things (IoT) is transforming several industries into smarter ones. In such situations, data collected from a number of sensors is used to generate insights that can be used to improve business decisions. Among the industries that are using IoT technologies are marinas, which traditionally were focused on sports activities, but are increasingly becoming living spaces and host cultural activities.

Traditionally, IoT projects are based on proprietary, application-specific or siloed, vertical solutions that require independent management ecosystems with poor integrations across domains. Moreover, many IoT solutions rely on remote cloud data centers for data storage and processing. This approach suffers from high latency, low bandwidth and high cost of data transportation. This work is part of a project that has received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 765452. The information and views set out in this publication are those of the author(s) and do not necessarily reflect the official opinion of the European Union. Neither the European Union institutions and bodies nor any person acting on their behalf may be held responsible for the use which may be made of the information contained therein.

In the last few years, fog computing has been proposed to reduce the latency and cost of delivering data to a remote cloud by bringing computation close to the sources of data [START_REF] Liu | A framework of fog computing: Architecture, challenges, and optimization[END_REF]. As such, fog computing complements IoT deployments by colocating computation with a group of sensors and allowing pre-processing of data in real-time, thus reducing latency and the amount of data sent to remote clouds.

Several fog computing platforms based on open-source technologies have been proposed. Among them, the LivingFog platform that integrates LoRaWAN technology with Kubernetes has been used for potable water management in València, Spain [START_REF] Arkian | Potable water management with integrated fog computing and lorawan technologies[END_REF]. This open-source platform has the potential to support sensors from multiple vendors, thus avoiding vertical siloes and independent management. Therefore, in this work, we extend the LivingFog platform to support multiple sensors in a smart marina setting at La Marina de València.

La Marina de València is a marina that is found in the Eastern part of Spain facing the Mediterranean Sea. The marina has two docks with mooring births, several restaurants, and public spaces. It is famous for having hosted the 32nd and 33rd America's Cups in 2007 and 2010.

In the past, the marina deployed few sensors: a meteorological station to monitor weather conditions, security cameras to monitor the area and stream to online visitors, people counters to measure the number of people coming to the area, as well as vehicle counters to measure the number of vehicles.

The FogGuru project, in collaboration with Las Naves, worked in this project to realize the marina's desire to expand the existing sensors and deploy additional ones. In a project that lasted seven months starting from September 2020, several sensors have been deployed at La Marina de València to measure parameters such as sea wave and current, water quality, weather conditions, number of people and number of vehicles. We also deployed a fog computing platform that enabled the processing of the sensor data in real time.

This project has four objectives:

1) Extend the LivingFog platform to support an integrated management of multiple sensors types [START_REF] Arkian | Potable water management with integrated fog computing and lorawan technologies[END_REF]. 2) Help La Marina de València realize its desire to setup an IoT and fog computing platform. 3) Address research and technical challenges such as resource management, multi-tenancy, security and data processing. 4) Enable a hackathon and IoT fablab so that citizens can exploit the data generated by the sensors themselves.

The rest of the paper is structured as follows. In Section II, we review some of the works in the literature that are similar to ours. In Section III, we discuss the requirement analysis for the project, the design decisions and the details of the implementation. In Section IV we use experimental measurements to show the advantages of the LivingFog platform in terms of reducing latency and reducing the number of messages that are sent to the cloud. In Section V, we describe some of the use cases based on our solution that were proposed by participants of the Hack the Fog hackathon. Finally, we conclude the paper in Section VI.

II. RELATED WORK

In recent years, the Internet of Things (IoT) has drawn significant attention from research and industry [START_REF] Li | The internet of things: A survey[END_REF]. IoT integrates several technologies and communication solutions [START_REF] Atzori | The internet of things: A survey[END_REF]. Using these technologies, different objects such as RFID tags, mobile devices, sensors and actuators interact and cooperate to achieve common business goals with minimal human intervention [START_REF] Atzori | The internet of things: A survey[END_REF], [START_REF] Mendez | Internet of things: Survey on security and privacy[END_REF]. IoT technologies are enabling several industries such as smart cities, smart homes, e-health, smart grid, manufacturing, security and smart grid.

One of the defining characteristics of IoT is the large amount of data generated by a vast number of sensors and mobile devices. These data need to be stored and processed to get insights and visualizations, and to be able to make decisions based on them. As IoT devices are mostly battery operated and have limited data storage and processing capacity, they need to be complemented by more powerful resources. Moreover, these devices cannot host application services directly due to the said resource constraints [START_REF] Puliafito | Fog computing for the internet of things: A survey[END_REF]. As a result, traditionally, the data generated by IoT devices is usually transported over long distances to centralized cloud data centers for processing and long-term storage.

Although centralized cloud computing data centers provide vast amounts of processing and storage capacity, they are concentrated in few locations that are considerably far away from the vast majority of IoT sensors, actuators and mobile devices. Such non-negligible distances from IoT devices results in some drawbacks such as high latency, congestion of narrowbandwidth networks and high cost of data transport over the network. To address these drawbacks, the fog computing paradigm is proposed, which extends the cloud by distributing computing, networking and storage resources to the network edge where data is generated [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF], [START_REF] Ahmed | Fog computing applications: Taxonomy and requirements[END_REF].

Despite fog computing being discussed vastly in academia, there are only few real-world implementations that are reported. Byers presents several requirements that a fog computing platform needs to fulfill and matches these requirements to several use cases from different industries. The author also presents a high-level software architecture for fog platforms without discussing implementation details and technologies used to achieve the platform [START_REF] Byers | Architectural imperatives for fog computing: Use cases, requirements, and architectural techniques for fog-enabled iot networks[END_REF].

Noghabi et al. explore several enterprises that use fog/edge computing presently in different industries such as business, smart cities, transportation and industrial plants [START_REF] Noghabi | The emerging landscape of edge computing[END_REF]. The authors explain the motivation behind the used of edge/fog computing in these enterprises and present a typical edge/fog deployment architecture without going into details about implementation and technologies used to achieve the specific deployments.

Yannuzzi et al. present a converged cloud/fog paradigm to address physical, data, service management and administrative siloes that smart city solutions suffer from, which they implemented in the city of Barcelona, Spain [START_REF] Yannuzzi | A new era for cities with fog computing[END_REF]. The authors present the architecture of the solution based on the ETSI MANO orchestration stack and five use cases where it was used.

Arkian et al. present a fog computing architecture based on open-source software integrated with LoRaWAN networking for potable water management in the city of València, Spain [START_REF] Arkian | Potable water management with integrated fog computing and lorawan technologies[END_REF]. However, the authors do not go into the details of the implementation of the platform apart from identifying the challenges that the platform addresses. Our work is based on this platform and extends it to support multiple sensors, multiple fog computing clusters, multi-tenancy and data management in the context of smart-marina management at La Marina de València.

III. DESIGN AND IMPLEMENTATION

In this section, we discuss in detail the design and implementation of the IoT and fog computing platform at La Marina de València.

A. Requirements analysis

The first requirement is to select sensors that capture the following parameters:

• Sea wave, current and related parameters The second requirement includes providing a fog computing platform for processing the data received from the several sensors as they arrive and make them readily available in a human readable format for the management of La Marina and other interested parties. Thirdly, the FogGuru researchers aim to address some research challenges with the IoT and fog computing platform such as:

• Support for multiple sensors • Resource management and application deployment in multiple fog computing clusters • Multi-tenancy and security • Data decoding and pre-processing

B. Selection of sensors

We selected the sensors shown in Table I based on the parameters that the marina wanted to be measured. The criteria for selecting the exact sensors was based on the fact that we are building up on and extending the LivingFog platform. As a consequence, all of the sensors except the sea wave sensor are based on LoRaWAN technology. As for the sea wave sensor, 4G was used as the networking technology to allow the transfer of large amounts of data that the sensor generates to the fog computing platform.

C. Sensor network

In order to forward the data generated by the sensors over LoRa to the fog computing platform, we use LoRaWAN gateways. We have selected two outdoor and three indoor gateways placed at different locations inside La Marina de València to forward the data from the sensors in their vicinities. The list of LoRa gateways used in this project is shown in Table II.

D. Fog platform hardware

Our fog computing platform is based on the Picocluster 5 and Picocluster 10 which are 5-node and 10-node clusters based on the Raspberry Pi 4B. These single-board computers are small and powerful enough as well as low-cost. They offer sufficient computing power and storage to store and process the sensor data. The list of fog computing clusters used in this project is shown in Table II.

E. Fog platform software

Apart from the challenges mentioned in a previous chapter, multiple software challenges were addressed in our fog platform. The platform is built using various open-source frameworks.

Various vendors and LoRaWAN devices: One design specification of creating a Fog platform was to build a platform using relatively powerful, lightweight, low-cost computers. The LivingFog platform used 60 Raspberry Pi single board computers, divided into 7 physical clusters. Plus, multiple LoRaWAN gateways and sensors had to be configured and integrated into the platform. Orchestrating a data exchange between multiple Fog computing clusters challenged us to use scalable cluster orchestration systems.

Continuous data flow from multi-vendor sensors: Continuous and consistent data flow from every sensor needed to be provided. We needed to use a common data protocol and had to design a custom data processing middleware.

Multi-tenancy and security: A fog computing platform should be used between multiple tenants. Meaning, multiple application developers must deploy their own fog applications using on the Fog platform, using the data the Fog platform provides. Also, the platform must support the secure connection and login from multiple application developers.

Resource management and scalability: The platform had to be created with scalability in mind. The Fog platform had to be scalable based on the data load and the number of tenants who are using the platform. Also, the resource management and the state of the platform itself must be monitored.

Kubernetes, an open-source container orchestration platform, is used to run multiple services on the fog clusters. Kubernetes is a portable, scalable and extensible resource manager that allows to deploy applications declaratively. Figure 3 shows the architecture of Kubernetes.

Figure 2 shows the overview of the configuration steps needed for application-ready Fog node. After creating the Kubernetes cluster, various software and services were deployed on a cluster to create an actual Fog platform.

Figure 4 shows the combination of multiple volumes into one volume using GlusterFS. GlusterFS (Gluster File System) is an open source Distributed File System that can scale out in building-block fashion to store multiple petabytes of data. The clustered file system pools storage servers over TCP/IP or InfiniBand Remote Direct Memory Access (RDMA), aggregating disk and memory and facilitating the centralized management of data through a unified global namespace. The software works with low-cost commodity computers and is based on Linux. Using GlusterFS, we were able to combine 5- 10 separate storages from multiple Raspberry Pis, ranges from 32GB to 64GB into one single 160GB to 640GB filesystem storage. This solution was needed when the data collected from multiple sensors grew periodically.

Figure 5 shows the relation between software stacks and services installed and configured on each cluster.

• Chirpstack Application Server -The ChirpStack Application Server is a LoRaWAN Application Server, compatible with the ChirpStack Network Server. It provides a web-interface and APIs for management of users, organizations, applications, gateways and devices. The received uplink data is forwarded to one or multiple configured integrations.

• Chirpstack Network Server -The ChirpStack Network

Server is a LoRaWAN Network Server, responsible for managing the state of the network. It has knowledge of device activations on the network and is able to handle join-requests when devices want to join the network. When data is received by multiple gateways, the Chirp-Stack Network Server will de-duplicate this data and forward it as one payload to the ChirpStack Application Server. When an application-server needs to send data back to a device, the ChirpStack Network Server will keep these items in queue, until it is able to send to one

F. Data Management Middleware

IoT devices, such as sensors, are an essential part of a fog-enabled IoT platform. These devices are the sources of data that provide abundant information about the monitoring environment and/or real-time events (e.g., the number of passing cars or pedestrians) , which can be used for application development. IoT devices deployed in IoT environments are from a variety of vendors and tend to produce a large volume of data on a daily basis [START_REF] Saqlain | Framework of an iot-based industrial data management for smart manufacturing[END_REF]. To manage the data well, some requirements emerge for the fog platform, which are described as follows:

• The heterogeneous data sources require fog platforms to manage the devices uniformly and make all the sensor data interoperable for applications • The vast volume of data requires high processing and storage capacity of the platform, among which data preprocessing is necessary to improve performance and to save bandwidth of data transmission. Moreover, both centralized and decentralized data storage are required to improve application performance. • The dynamic nature of IoT devices (e.g., adding them to a network in a flexible manner) requires fog platforms to be able to discover the devices without any manual interventions. To meet the above requirements, our LivingFog platform includes a data management middleware that can holistically manage the massive volume of data from various IoT devices. It supports device discovery and enables the development of batch and stream processing applications using real-time and historical data. In addition, this middleware can be deployed as an individual service in Kubernetes, making it scalable to the number of fog nodes.

Figure 6 gives an overview of our data management middleware. There are two inputs: sensor data from the MQTT broker (encapsulated in LoRaWAN format) and customized sensor information, including the device identifiers, sensor parameters, and LoRaWAN protocols.

The middleware subscribes to the MQTT broker via topics and processes the data stream received from sensors. The data from the MQTT broker are decoded and formatted with the LoRaWAN protocol of the sending sensor.

After receiving the data, the middleware recognizes the sensor type by matching the device identifiers and reads the measured data using the LoRaWAN protocols provided in the input. Lastly, the readable sensor data are sent to a local database running in the fog cluster and also forwarded to a global database in the centralized cloud.

G. Monitoring

Monitoring is critical for a fog platform to guarantee the availability and reliability of the applications and resources. For instance, resource metrics can be used to detect overor under-utilization of resources [START_REF] Battula | An efficient resource monitoring service for fog computing environments[END_REF], [START_REF] Prasad | Influence of montoring: Fog and edge computing[END_REF]. In addition, the observational metrics provided by a monitoring system also play a vital role in providing advanced services such as scheduling, scaling and migration.

To this end, our Livingfog platform is equipped with a monitoring stack that tracks and collects information about computing resources, the status of computing devices, and the performance of deployed services (e.g., network server in Chirpstack). This monitoring stack is composed of a set of tools, including Node-exporters 1 for resource utilization of fog nodes, kube-state-metrics 2 for the status of the Kubernetes orchestration platform, cAdvisor 3 for resource utilization of containers on which services run. All the data collected by the above tools are centralized in Prometheus 4 , where the metrics can be queried, and from which alerts for unexpected events can be sent if so configured. Moreover, Grafana 5 is used for visualizing the data stored in Prometheus.

H. Security features of the platform

One of the objectives of the LivingFog platform is to enable a hackathon and IoT fablab so that citizens can make use of the data generated by the sensors. In this objective, citizens who are interested in developing fog computing applications should be able to access our fog platform and deploy their application on it. Therefore, we need to define the users' access level to the resources of the platform in such a way as to provide enough freedom for the application developer, and at the same time to prevent them from any unauthorized access to other users' or the platform's resources. During the hackathon, the importance of the separation of the users in the form of teams and also the protection of their assets increases.

As our fog platform is based on Kubernetes, we use Kubernetes' role-based access control (RBAC) mechanism to define the roles and their corresponding access level. When defining a role, we specify the resources that each role has access to them and the actions that can be performed on that resource using the role. After defining roles, we generate a token that grants access to the platform concerning the defined role in the team namespace. 1 Node-exporter -https://github.com/prometheus/node exporter 2 kube-state-metrics -https://github.com/kubernetes/kube-state-metrics 3 cAdvisor -https://github.com/google/cadvisor 4 Prometheus -https://prometheus.io/ 5 Grafana -https://grafana.com The fog nodes have a limited amount of CPU and memory resources. As our fog platform hosts multiple applications from different teams simultaneously, we anticipated a condition where some hackathon teams exhaust the platform resources and disturb other teams. To avoid such conditions, we exploited the Kubernetes resource quota. This mechanism in Kubernetes allows us to define a quota for the said resources at the container level. However, we defined some default values for the CPU and memory usage by each container to facilitate the use of our platform.

IV. EVALUATION

In this section, we present the performance of the LivingFog platform as compared to a traditional cloud-only deployment.

We use the number of messages sent over the network and network latency as metrics to compare the two deployments.

Figure 7 shows the number of cumulative messages sent by the sensors deployed at La Marina de València during a day. In a traditional cloud-only deployment, all messages from all sensors should be sent directly to the cloud platform over long distances. As a result, we see a large number of messages sent amounting to a cumulative of 54,720 messages per day. In contrast, in the case of the fog-cloud deployment scenario, sensor messages are sent directly to the fog platform for preprocessing and only messages containing aggregate values are sent to the cloud every hour for visualization and persistent storage. In the latter case, a total of 552 messages are sent to the cloud during a period of 24 hours.

Figure 8 shows the network latency for publishing sensor messages to MQTT brokers in the fog and cloud platforms. We see that publishing messages to the MQTT broker on the fog platform takes on average only 4 ms, whereas sending messages from the sensors to an MQTT broker in the cloud (hosted in hivemq.com in this case) takes on average 40 ms. Clearly, this shows the advantage of fog deployments in reducing network latency significantly.

V. USE CASES

In this section, we describe the top three use cases introduced by teams of the "Hack the Fog!" hackathon 6 . The two main parameters for selecting the winner use case were: First, The usefulness of the use case, and second, the level of technology that the team used for prototyping their applications. Table III represents the top three selected use cases.

The first place went to "Fog pandits" team. They target the water siltation problem. Siltation is the water pollution caused by particulate terrestrial clastic material, with a particle size dominated by silt or clay [START_REF]Siltation[END_REF]. Water siltation prevents the passage of vessels and decreases water quality and biodiversity. The team's approach is to use the sensors data to model the siltation in water and notify La Marina with the exact location where the level of siltation is above the normal level. The said team utilized the data received by sea wave, current profiler, and water quality sensors to feed the stiltation model. They deployed their application using Node-RED 7 for processing the streams of sensors data in real-time.

The second winning team was "Marina Connect". The team developed an application for both the restaurant owners in La Marina area and their customers. The restaurants located in the La Marina area may face decrease in the number of their customers due to pandemics or bad weather conditions. On the other hand, customers prefer to go to the restaurants knowing that the place is not crowded in Covid pandemic situations 8 . The Marina Connect application uses real time sensor data of people counter, car counter, weather station sensors (air temperature and precipitation data) and wind sensors along with the historical data of these sensors stored in the cloud to predict the people congest in the La Marina area. Based on this information, the application sends incentives to the potential restaurants' customers to enjoy attending the restaurants.

The third winning application of the hackathon was "Hodor". The application targets a similar problem to the previous application, hence with a wider range of audiences. This application uses sensors data to notify people if they can attend different spots of La Marina without risking their health in pandemic situations. The application takes into account the data of people counter sensors, wind sensors, weather station sensor and water temperature sensors to decide whether it is safe for an individual to enter an spot in La Marina.

VI. CONCLUSION

In this paper, we present an experience report of the LivingFog fog computing platform integrated with LoRaWAN technology that has been used for a smart marina project at La Marina de València, Spain. In this project, several sensors were deployed inside La Marina to measure various parameters of the sea, weather, movement of people and vehicles. The data collected from the sensors is processed on the fog computing platforms. We report on the performance of the platform in terms of latency reduction and saving of bandwidth. Moreover, the platform has been used to deploy various applications by participants of the "Hack the fog" hackathon to validate their innovative ideas. The platform is available under a liberal open-source licence 9 . We hope this paper encourages other researchers to report on similar fog platforms.

Fig. 1 :

 1 Fig. 1: High level architecture of the IoT and fog computing platform at La Marina de València.

Fig. 2 :Fig. 3 :

 23 Fig. 2: Software stack layers deployed on the Fog platform

FSFig. 4 :

 4 Fig. 4: Data storage using the GlusterFS scalable network filesystem.

Fig. 5 :

 5 Fig. 5: Software stack and its data stream

Fig. 6 :

 6 Fig. 6: Data management middleware in the LivingFog Platform.

Fig. 7 :

 7 Fig. 7: Cumulative number of messages for a day.

Fig. 8 :

 8 Fig. 8: Latency (msec) of publishing to MQTT topics.

TABLE I :

 I Type and number of sensors selected for the project as well as the parameters they measure.

	No. Sensor name	Model	Parameters	Qty
	1	Sea wave and current	Nortek AWAC 1MHz	Sea wave, current, temperature, pressure	1
	2	Weather station	Libelium-Gill-EX-Machina Smart Weather	Temperature, humidity, air pressure, rain fall	1
			Forecast LoRaWAN Solution Kit	level, solar radiation
	3	Wind sensor	DecentLab DL-ATM22	Wind speed, direction, air temperature	3
	4	Water quality sensor	Libelium-Thing+ LoRaWAN Smart Fish	Conductivity, pH, dissolved oxygen, water	1
			Farming Solution Kit	temperature, Ammonium ion, Nitrite ion
	5	Traffic counter	Parametric TCR-LS slow traffic counter	No. of vehicles, speed	10
			with LoRaWAN
	6	People counter	Parametric PCR2-OD outdoor radar people	No. of pedestrians	4
			counter with LoRaWAN
	7	Indoor environment sensor	enLink Air wireless air quality sensor	Temperature, humidity, light Level, VOCs	3
				(Volatile Organic Compound), Carbon
				Dioxide, particulate matter (PM2.5 &
				PM10), Oxygen, sound level, barometric
				pressure

TABLE II :

 II List of LoRa gateways and fog computing clusters used in the project.

The hackathon, in which 63 participants used the LivingFog platform and the data collected from the sensors to validate their ideas, took place from 26 to 28 March, 2021 in Valencia and fully online from 26 to 28 March, 2021 https://ec.europa.eu/info/events/hack-fog-2021-mar-26 en.

Node-RED -https://nodered.org/

Crowding is one of the main factors in increasing the risk of respiratory viral infections[START_REF] Rader | Crowding and the shape of covid-19 epidemics[END_REF].