# Harnessing the Cloud: A Novel Approach to Smart Solar Plant Monitoring
## 4 Our Proposed Architecture for Smart Solar Plant
### Cloud-Based Implementation  
A huge amount of data is generated through solar plant monitoring, making data management a pressing issue from a sustainability perspective. For example, it was reported that 8 Gb/s of data will be generated by a 500 MW solar plant (with 2,500,000 solar panels each rated to produce 200 W) [5]. Although data cleansing techniques can be employed at the edge layer, monitoring the data is still a huge task for any local server, thus necessitating the employment of cloud computing platforms. In the application layer, these accumulated data are regulated, cleansed, and archived for analysis, as can be seen in Figure 3. Furthermore, an interface is provided for users and stakeholders to access, manage, and perform data analytics for fault diagnostics and information dissemination. In this context, cloud platforms have emerged as the optimum solution for application layer deployment. The salient features of cloud platforms are their high availability, reliability, and scalability. Furthermore, they provide a variety of network services, hardware resource virtualization, and scalability to handle huge amounts of data exchange, sharing, and management [53]. The most common cloud platforms employed for solar panel monitoring in the existing literature are detailed in Table 7. It provides a detailed profile of the cloud platforms mentioned in the literature. It lists the communication protocol supported by each platform, openness, security mechanism employed, write rate, and list of compatible devices. It also highlights whether the platform has an option for messaging/notification services such as email, SMS, or Twitter. To explain further, write rate refers to the interval frequency at which data are sent to the platform, e.g., ThingSpeak sends an update every 15 s and Blynk sends updates every second. For other platforms such as Ubidots, AWS, and ThingsBaord, the data rate may vary, depending on the deployment and configurations. Regarding the notification service, some platforms may not have native support for a notification service but it can be integrated through an external service or an API, denoted by '(ext-int)' in the table. These attributes are crucial to compare cloud-based IoT platforms on various technical needs. Selecting the appropriate platform will help the design architect to steer the technology according to the project technical requirements and limitations. These commonly employed cloud platforms such as ThingSpeak, ThingsBoard, Blynk, and Ubidots are both open-source and free to use but these platforms have serious limitations such as the number of maximum connected nodes, data upload rates, and the number of requests or messages per second. The public cloud platform Amazon Web Services (AWS) is therefore proposed for its capabilities, rich support and documentation, and the variety of tools that it offers. The choice of cloud platform depends on personal preference and may vary according to the project-specific needs. In our proposed architecture, we are going with AWS because it offers a comprehensive suite of services offering integration options with other AWS services and other third-party applications, robust security, dynamic scaling to support large-scale systems, tools for AI/machine learning, and other managed services like AWS IoT Core, AWS IoT Analytics, and AWS IoT Greengrass, which are specifically tailored for deploying, maintaining, and scaling IoT infrastructures. Figure 5: This figure shows block diagram of the end node, comprising a few meteorological sensors, a compute board, and a communication technology (GSM) for data transmission to the cloud. Using AWS serverless IoT, sensed parameters can be employed for information processing and analysis to generate desired reports for performance evaulation.