# FLIP: A New Approach for Easing the Use of Federated Learning
## 4 V&V: Validation and Verification of the Platform
### Functional Validation  
To validate the platform deployment, two methods are tested: running a bash script on each node and using Jenkins. The first approach is easier and faster, but it requires the registration of client nodes on the server's database through the dashboard. On the contrary, the use of Jenkins is more complicated because it requires a previous setup of Jenkins on all nodes. However, once this is completed, the registration of clients is not necessary and the maintenance is easier. Additionally, Jenkins benefits from the advantages of continuous integration. In general, both approaches have their own pros and cons, and the choice of which to use depends on the specific needs and requirements of the deployment. In some cases, the simplicity and speed of the bash script approach may be sufficient, while in other cases, the advanced features and capabilities of Jenkins may be necessary. To thoroughly validate the model and the platform on which it is executed, we run the neural network model in both a local and a federated environment. This firstly allows us to assess the correct execution of the whole system and to compare the throughput and resource demands of both settings and determine the benefits and drawbacks of each approach. For experiments using the NN model in a local environment, we chose to use a total of 20 epochs, which means that the dataset iterates 20 complete times during training. This number is selected based on the simplicity of the model and the fact that the prediction \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Server** & **RAM Size** & **CPU** & **Graphic Card** & **Dataset Size (No. of Samples)** \\ \hline MacBook PRO & 16 GB & 2.20 GHz intel i7 & No & 12,441 \\ Unix Server 1 & 48 GB & 2.80 GHz intel i9 & No & 49,767 \\ Unix Server 2 & 32 GB & 3.50 GHz intel i7 & NVIDIA TITAN RTX 24 GB & 62,208 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Summary of the capabilities of the client nodes and the size of the dataset used for functional validation. required is not complex. In the federated environment, we establish 20 global rounds and 1 local epoch for the NN model, which means that the algorithm iterates 20 times, but after each epoch, the aggregation strategy is performed to update the model's parameters. We choose the federated average, which consists of averaging the weights, as the model aggregation rule, as our intention is to focus on the performance of our platform without entering too much detail regarding distributed optimisation theory. Moreover, it is simple and achieves great performance if the federated datasets originate from the same distribution. The dataset for each node is divided into 80% for model training and 20% for model validation. This allows us to evaluate the performance of the model on unseen data and to test its generalisation performance. The results in Table 3 indicate that, in this specific case, federating NN improves performance compared to isolated training. Bear in mind that we do not want to state that federated learning improves isolated training, as it depends on the properties of federated datasets. A possible explanation is that all the datasets have the same distribution, with no attribute loss or noisy values, and thus the overall score is quite similar. Moreover, with respect to time, throughput becomes affected because the server must wait for the delivery of all partially fitted model replicas, including the slower ones, thus the overall score is lowered. Despite the longer time, these nodes are rewarded with better results. It is also worth noting that memory usage is similar for all cases, so the use of federation does not significantly increase server resource usage. This, together with the time, allows a low impact on the performance so that algorithms, which can be resource-hungry, can still use most of the memory.