Abstract
Internet of Things (IoT) is a phenomenon involving connecting things or objects with sensors. The IoT market is growing rapidly, and there are strong incentives for companies to follow the trend of IoT growth and development. However, the percentage of IoT measures that are considered successful seems low. The complexity of carrying out an IoT project lies in the need to adjust all the pieces of the puzzle: assets, sensors, communications, technology, coverage, and geographical locations with precision of the measures and regulations. All these requirements determine the economic viability of the business and its benefit. This study, therefore, examines how the project methodology can support the development of the concept and ensure the business value of IoT initiatives. The project methodology developed in this study is called PoC Design. A case study was evaluated, in which defects in street lighting were investigated and carried out. The evaluation of the methodology highlighted the importance of defining problems and solutions based on business value, calculating the potential of an IoT initiative, determining the continuation of the project, involving stakeholders at an early stage, and creating a PoC to validate the concept with stakeholders.
1. Introduction
In software development, the term “proof of concept” (PoC) can be an essential tool to demonstrate the capabilities and suitability of the software for the needs of clients and to show that the concept is feasible and meets the needs of customers. While some applications are proof of concept in various fields, from marketing to medicine; in terms of software development, we are talking about a specific process that may take the development of hardware, websites, or other software to implement a concept. This process is designed to determine whether a software concept can be created in the real world, what technology to use for development, and whether the intended users are likely to use the software.
Internet of Things (IoT) is a network of physical and virtual objects, devices, or things that can collect data from the environment and communicate with each other or through the Internet [1, 2]. In 2019, it is expected to reach 14.2 billion internal connected devices. By 2021, its number is expected to increase to 25 billion [3], but a study by Cisco Systems showed that just over 40% of all IoT initiatives move away from PoC levels and only 26% are estimated to be successful. For this reason, there are doubts about integrating the complexity of IoT initiatives into existing network and application architectures [4], and therefore the use of methodologies that can reduce complexity should be able to increase the number of IoT initiatives that are considered successful.
The concept of the Internet of Things (IoT-PoC) is evidence of the concept of low risk, which is the perfect way to bring IoT to any business. Proof of concepts is to ensure IoT for smart and secure, real-time data results, testing for technical failures, compatibility, dependency, and accuracy. PoC aims to test a solution in your environment, collect data, and evaluate output. Effective IoT initiatives show that factors such as community, organization, and leadership influence the effectiveness of initiatives [4]. These considerations are not related to the technological choices made in the project but to the complexity of the people involved in the project. Thus, IoT initiatives not only involve the construction of an interconnected unit but also require implementation that leads to business benefits and improved operations. Synergies between business and technology are therefore crucial for IoT initiatives.
In the literature, several project methodologies are used to streamline project work of different origins for a specific purpose. Extreme programming to improve software quality and respond to changing needs in software projects [5]. For this reason, this study presents a project methodology for developing an Internet of Things-proof of concept (IoT-PoC).
This study aims to combine new studies and methodologies for IoT-PoC development. The study is sponsored by a manufacturer of luminaries and lighting fixtures. There is a common interest in exploring how IoT-PoC can be developed to create the best conditions for product conversion. The idea of developing a PoC error detector for outdoor lighting was developed in negotiations with the client. PoC was developed in a study to detect outdoor lighting failures. The results of the evaluation can be used to improve and increase the share of successful IoT initiatives and to avoid unnecessary use of resources.
The paper is organized as follows. Section 2 presents basic preliminaries and related research work associated with the proof of concept. Section 3 describes the PoC Design methodology to design the proof of concept in IoT-connected environments. Section 4 presents results, and Section 5 describes evaluation analysis on proof of concept. Finally, Section 6 clinches the proposed PoC Design methodology along with future directions.
2. Basic Preliminaries and Related Research
2.1. Problem Formulation
This study aims to derive a project methodology based on the existing literature and consultation methodologies to support the development and evolution of IoT-PoC. The study proposes a project methodology used in consulting operations to develop IoT solutions. The methodology published in the field and the methodologies based on interviews with selected consultants are limited. The methodology will be implemented and evaluated through a case study developing IoT-PoC. This PoC aims to detect defects in outdoor lighting, especially street and park lighting. Emphasis will be placed on project work and how methodologies add quality and relevance to technological and business benefits. The impact of cultural differences on the outcome of the project is very important but will not be examined in the context of this study.
2.2. Literature Study
The application of IoT technology in metrology is a relatively new topic. “Smart Metrology” means huge amounts of data captured in a business should be utilized only when it is reliable as stated by Lazzari et al. [6]. Smart metrology is proposed as a solution as a novel understanding of metrology focused on reliability. It urges metrologists to reevaluate calibration intervals rather than obeying the law's mandate for regular calibrations as an example of the benefits of this strategy.
Daponte et al. presented measurement applications based on IoT in a literature review [7]. The authors conducted research in a variety of domains, including smart factory, smart building, smart environment, smart energy, connected and smart health, and finally intelligent transportation systems.
In article [8], the author discussed various technologies used in smart grids that include Internet of Things and smart meters. Existing smart grid connectivity methods are also covered in the literature.
More connected and smarter solutions for smart grids are provided by the authors’ company.
As in article [9], Angrisani et al. offered a test equipment platform that is fully automated based on LabVIEW. While training personnel, it is risky to have all the required gadgets in the same lab; in such scenario, it is better to share its resources with other labs, and this platform is capable of offering additionally remote access and programming the devices.
Real-time data can be collected and combined by using the Internet of Things, which offers greater efficiency while operating the system [10]. In sunscreen monitoring application, there is no significant state of art available where integration of IoT is discussed. To activate an emergency alarm, data such as humidity, UV index, CO2, temperature, and heart rate are captured in the healthcare application by using wearable devices based on IoT as stated in the article by Wu et al. [11].Gateways are used between the LoWPANs, which are having transmission capacities like 926 meters and 520 meters outdoor and indoor, respectively, and the data collected using the wearable devices will be sent through these gateways from one LoWPAN to another. In article [11], the authors presented a study where UVR-exposed person data can be used for improving the safety and health programs in the workplace. In article [12], the authors presented a work where the IoT can be used for keeping the restroom clean.
To fully realize the potential and to support and contribute to innovations that are based on evidences in IoT, an assessment of their influence is required, and also a plan for engaging final customers and conveying the advantages was obtained using captured data.
Ensure adequate availability of the network; develop a robust product for managing the system, which will be integrated with existing organizational domains; environments with raised UV levels are used for storage; and cautiously configure the product to minimize security risks and privacy are all critical technical considerations for a successful deployment.
The study addresses the lack of a framework for managing the integration of software components into IoT applications [5]. The study describes a model-driven development (MDD) consisting of four phases for the development of an IoT application (see Figure 1).
The methodology is based on the generation of models in four phases where the output from each phase is used in the next phase. The requirements set by the store are inputs to the methodology. In the first phase, the problem domain is analyzed and requirements for the business are identified. Requirements are identified concerning functional and nonfunctional requirements. The model is generated based on business requirements, activity diagrams that show the flow through the application, and use cases for the IoT application. The model generated is at a high abstraction level. Phase 2 focuses on the design of the business process. The business process must support the business logic and the requirements set by the business. The abstract model for a business solution is generated based on the business process, together with the business requirements model generated from the previous phase. The business solution model describes the behavior and interactions of the business process from a global perspective.
A model for the system architecture is generated and defined in the third phase. The model is generated based on a service-oriented architecture (SOA) as shown in Figure 2. The model is defined at an abstract level, which means that the model can be reused on several platforms. The interaction between system components and sensor nodes is central to IoT systems. For this reason, the authors have developed an architecture that will make the design of the system simpler. The layers of the system architecture are described in the following sections.
2.3. Layer 1: Object Layer
The first layer consists of nodes connected to the network. All nodes have a unique digital identity to identify nodes within the network. Nodes collect data about their environment and may also affect the environment in some applications. The data collected shall be transferred to the remaining stocks.
2.4. Layer 2: Network Layer
The network layer allows the communication of messages and events between connected objects and systems. The warehouse is critical to any IoT application in terms of ensuring the quality of traffic connections and that the packets sent are sent and received. Energy efficiency, signal and data processing, safety, and integrity are important aspects that should be taken into account in the warehouse [13].
2.5. Layer 3: Service Layer
The service warehouse shall handle the services and information requested by the user or the software. A large number of connected devices (e.g., connected light points in a park) are often used in IoT systems to communicate messages. The challenges for the service warehouse arise, among other things, from the varying number of connected devices and the handling of messages and tasks within the system. The layer is one of the most critical architectures, as it should support bidirectional communication between the application layer and the object layer.
2.6. Layer 4: Application Layer
The last layer is the interface between user and system. The warehouse is responsible for delivering information to and receiving information from users.
The technical solution is being developed in the last phase. Development takes place in two stages. In the first step, a platform-specific model is designed based on the system architecture of the previous phase. In step two, the platform-specific model is converted into a code. The code could be a skeleton or an executable code.
The authors proposed a two-step model in the study [14]. In the first step, the system architecture consists of four layers: data acquisition and transmission, data processing, cloud, and finally visualization. The second step sets out the selection criteria for both hardware and software components. The authors conducted a case study using the proposed methodology to develop an IoT system. The purpose of the system was to measure temperature and moisture content at several locations in the office. The approach used by these authors is very interesting for the current research; that is, to establish and suggest a technique, and then to implement it in a case study. The layout of the device architecture in the methodology is comparable to the methodology in the study mentioned above [5]. However, the development of system architecture is at a lower level of abstraction and requires technologies that can make the design difficult to move to multiple platforms. Nor does the methodology address any assessment or assessment of business requirements or business benefits in IoT projects. As in article [15], the authors stated that the context will have a high level of heterogeneity where interactions and infrastructure belongs to IT in near future needs to obey guidelines of human-computer interactions.
In the analysis, the authors examined and addressed current methodologies for designing IoT systems [16]. Methodologies are important for practical exercises focused on the essence framework [17]. Two of the exercises—stakeholder and opportunity—are particularly interesting for this review. For each exercise, there is a checklist shown in Figure 3. The stakeholder's exercise requires the involvement and agreement of stakeholders in the project; while the opportunity exercise includes assessing and defining challenges, strategies, and values for the IoT project.
Research explains the approach to the choice of communication technologies for IoT solutions [18]. To simplify this option, the authors produced a questionnaire in which answers to various questions exclude such communication technologies. The concerns concerned the extent of contact, the use of power, and also cost-related issues, such as licensing fees. The analysis is interesting because it shows that the technology choices made in the IoT project are not trivial [19]. The choice of technology not only affects efficiency and capabilities but also affects short-term and long-term costs in and after the IoT project [20].
The literature study shows that there are methodologies to be used in projects to build IoT systems, but that methodologies are designed to develop IoT systems and not unique to IoT-PoC. To establish a methodology, specifically for the creation of IoT-PoC, the methodologies for literature research need to be supplemented. Interviews would also be conducted with experts from consulting firms working on the implementation of IoT systems. Emphasis will be placed on methodologies for the production of IoT systems and, above all, on how work is carried out up to and including the development of IoT-PoC.
3. PoC Design Methodology
The new IoT-PoC development methodology was designed based on extreme programming and has been named PoC Design. The purpose of the PoC Design methodology is to enhance IoT-PoC development. With improvement, the number of successful IoT projects may increase. The methodology is based on clarifying a problem or need. The key is to solve the problem or satisfy the need. A solution that does not provide commercial value to the customer should not be developed but should be quickly rejected, and new solutions should be developed [21]. The solution, which is considered to have the best potential and capacity, is used in the development phase. As a result, no PoC is developed that is not rooted in a problem, need, or business advantage. The idea is that no resources should be spent on solutions that do not generate enough value in return.
There are five stages in the PoC Design methodology. Stages 1–3 must have a four-week time frame, and each iteration in stage 4 also requires four-week time frame. The reason for the established time frames is that a short time frame (day or week) can be seen as a challenge, and a long time frame (more than six weeks) is seen as an obstacle that reduces work motivation [22]. Stimulating the middle between the short and long time frame can motivate the people involved and shorten the development time at the same time. The basic idea of the methodology is to encourage innovation and dare to test, develop, and validate concepts [23]. This is done according to the fail fast procedure. Parts of the consultancy firms' methodologies, which contained the same elements, were voluntarily adopted into the PoC Design methodology. However, in terms of separating the steps, it was necessary to select what is considered to be the most important PoC Design methodology. The result was that the segments were considered the most important consulting firms in their respective methodologies. The four steps of the methodology are shown in Figure 4 and described in the following sections.
3.1. Stage 1: Problem
At the outset of the project, these three consulting firms had a common type of workshop and feasibility study. They said it was important to map projects and define the formulation of the problem together with the customer. According to Knowit and Attentec, a measurable target image needs to be defined at the beginning of the project so that the project can be evaluated when it is ready.
For the first step of PoC Design methodology, the main objective is to define the problem and the target. The definition of the problem and the goal must be rooted in business benefit. The layout inside the table varies depending on the angle of incidence. Either a project with a known opportunity or a problem is created at the request of the customer. Opportunities may arise from knowledge from previous projects or opportunities identified in the field. The options may be in a previously unexplored area that must be explored before the option can be considered. To understand the areas of opportunity and potential actors, a feasibility study is conducted in the next step.
The feasibility study identifies key actors, customers, and conditions in the field. For example, a feasibility study could include an analysis of the latest results, market analysis for the market, or the existence of IoT solutions today. It may also include basic technical conditions, such as an estimate of the required range and sensitivity to data storage.
If the project is based on a customer request, the feasibility study should broaden the customer’s understanding. This complements the sense of customer business and organization that does not follow from the workshop. The feasibility study incorporates previous analyses but is complemented by customer assumptions about existing infrastructures and technical specifications, value design, and organization.
The workshop focuses on understanding customers and stakeholders, identifying their business, and the right problems. According to Attentec, customer expertise is central because the customer is an expert in the field of technology in which the project is carried out. To identify the right problem, the customer should be included in the workshop. The customer may be an external end consumer or an internal part of the company that may be affected by the IoT solution. The seminar should bring together different parts of the customer organization. Valuable insights can be gained at a meeting between different parts of the organization or between stakeholders. They can improve the definition of purpose, problems, and goals, which becomes more relevant.
If an objective is to be identified and defined, business advantage must have the highest priority. To evaluate the business benefit, it is necessary to consider both internal and external factors. This is important because IoT solutions can generate both internal and external benefits.
It is also important to set project goals. The objectives are to be used in part in the evaluation at the end of the project. Goals are to be achieved in part during the project. These are needed when reorganizing the solution because the solution must always meet the definition of purpose and goal.
Host's actual benefit for reports, the owner of the product should be appointed. The owner of the product can be a stakeholder in the workshop. The product owner is responsible for defining the problem and the aims of the solution. Responsibility continues at all stages, and the product owner must be involved in all stages of the project. IoT solutions often influence a company’s business model and offering. Therefore, responsible decision-makers should be involved. Therefore, in the case of small- and medium-sized companies, the CEO and management of the company should be involved in the process.
3.2. Stage 2: Optimal Solution
According to WSI, finding the right solution is as important as finding the right problem. In solving problems, several solutions can be developed that solve the same definition of the problem.
At this stage, it is important to choose an abstract solution that will create the greatest business benefit for the customer. The abstract solution does not describe the technical specifications but describes the solution at the overall level. At this stage, according to WSI, it is also important to expand the range of ideas for each solution. This means putting current and future opportunities and challenges into perspective for each solution. This is an important part of comparing solutions. Solutions that solve today's problems but do not meet future challenges can be considered less. The outcome of the solution phase generates the greatest business benefit and can meet the definition of the problem and the goal.
3.3. Stage 3: Potential
Step 3 can be considered a decision point and as a further evaluation of the solution, leading to measurable potential. According to WSI, it is not the technology that limits the potential of the project, but the business benefits it creates. The potential is determined by making an investment calculation.
It is important to think back and evaluate whether the solution meets the definition of the problem and the goal. The potential is calculated based on the previous steps. The outcome of the potential determines whether the project proceeds in phase 4, where PoC is developed. It is important to avoid unnecessary costs that arise when developing a PoC that does not result in a sharp product or service. Therefore, before you start the development of PoC, it is necessary to determine whether the project has potential or not. If there is no capacity, there are shortcomings in the definition of the problem and the purpose, or in the solution itself. The action consists of a backward diversion and taking the necessary actions or completing the project. This is an important step in developing solutions that are not rooted in business benefits and therefore risk failure.
3.4. Stage 4: PoC Designing
From interviews with consulting firms, the perspective of PoC development is fragmented. According to WSI, it is not always necessary to use resources to create PoC, as technology is often not a limiting factor in an IoT project. On the other hand, Knowit wants to develop a PoC for each project as a basis for decision-making and demonstration and evaluation purposes. It is important to clarify the definition of PoC. In PoC Design methodology, the aim of PoC is not to test the technology but to present the concept to the customer and facilitate its evaluation and verification. PoC should not be a fully functional product, but it could be, for example, an application environment without proper functionality. Therefore, it is considered a useful tool that does not require unnecessary resources.
In the fourth step of PoC Design methodology, it is, therefore, necessary to create a PoC. In the first version, PoC is created. Based on the evaluation, there is an incremental development of PoC or an overall design transformation for PoC. When PoC is deemed suitable for the market, PoC is ready. Each iteration has four stages, as described below.
3.4.1. Design
In the design phase, the abstract solution is changed from phase 2 to design. Material from previous phases of the project, a feasibility study, and a workshop are used to generate a design that is relevant to the area and the customer. An example of this is if the concept can be integrated into the existing customer infrastructure, or if the concept requires new infrastructure.
In the first phase of the design phase, the overall architecture of the system defined in Figure 2 is used. When defining the system architecture, it must be based on modules. Modular system architecture means defining the interface between layers so that modules can be replaced without interrupting other layers. The ability to replace bearings creates a flexible concept that is important for converting PoC to a sharp product. Then, there may be a desire, for example, to choose a particular cloud service provider, run your server, etc.
Each input layer is then defined in the system architecture. The components to be used in the warehouse are selected based on the technical specifications defined in the previous stages of the project. The topology of the network is defined by showing how the network communicates with the remaining layers with the sensing nodes and possibly the gates. Also, all the sensors to be used or what communication protocol to use are all the key issues that must be considered according to the design definition.
3.4.2. Build
Once the design is defined, PoC evolves. To avoid the high development costs, it must be built quickly, easily, and cheaply. This may mean that the functionality is implemented or imagined. PoC can include software or hardware, or both. PoC should not be a finished product, but it should envision the concept. For example, PoC may be an application environment without real functionality. When developing with hardware, existing components should take precedence over new ones. The advantage of using existing components is that they do not waste time designing, for example, printed circuit boards. The purpose of PoC is to verify the concept and not to develop components.
3.4.3. Evaluation
As part of the evaluation, a PoC evaluation is performed and feedback is given on the definition of the problem and the target. The evaluation can be done in different ways, but it is important to reflect on the definition of the problem and the goal, as well as the abstract description of the solution. Back to consider whether the PoC iteration generated the problem and meets the aims. In the future, it should be considered together with the product owner and the customer to ensure a concept that meets expectations and can be the basis for a sharp product. Evaluation together with the customer and market stakeholders is important to minimize the risk that the development will not be in line with the customer or the market. The outcome of the evaluation is the basis for determining whether the PoC is ready for scaling to a steep product or whether some iteration is required. Regardless of the decision, the evaluation will move to the final stage in the phase.
3.4.4. Learn
Following the evaluation, it is important to use the experience gained whether or not PoC is considered market friendly. If PoC is not considered suitable as a market, it is important to learn from the evaluation and use it as input to a new version. If PoC is considered market friendly, the concept is clear. The concept can now be augmented to be a sharp product. However, it is still important to use the lessons learned from the process in future projects. This means that successful concepts can be used to identify new opportunities and can be used in other application areas.
4. Results and Discussion
The results obtained are analyzed and discussed in this section about the study's problem formulation. It also provides the reader an insight into how the proposed methodology influenced the results and reflections from the case study. The proposed PoC Design methodology was applied to a case study to see effects and outcomes from each stage of the methodology in an IoT environment. A case study was chosen from the Housing and Urban Development Department of an Indian municipality that has initiated an IoT-based street lighting project with minimum investment and maintenance. Street lighting can consume up to 40% of a city's energy budget. IoT-enabled street lighting control can halve that cost, and remote monitoring can detect faulty bulbs in real time, allowing a repair crew to arrive before nightfall.
Smart lighting has various advantages, including lower power usage with smart dimming and automatic failure detection. It was chosen to investigate and evaluate the ability to detect and report defects in outdoor lighting with its 150,000 LED spots. The proposed approach uses the powered 20W LED street lights. The power consumption in 8 hours is 96 watt.hr. The typical types of errors that are designed to detect are no light, light by day, flickering light, power failure, and leaning pole, and the sources of errors are input current (too high, low, or missing), moisture, temperature, voltage transients (e.g., lightning strikes), and open output circuit. The priority levels of errors are categorized as low severity, medium severity, and high severity. Three methods are available in the system for assigning a location to lamps: automatic positioning via GPS, automatic placement via proximity beacons and a mobile application at the time of installation, and manual positioning via a map.
A semistructured interview was considered to correspond to the workshop step in the proposed methodology. During the interview, the results from the feasibility study were discussed, which confirmed but also denied certain parts.
The result was compiled in a problem and goal definition: Faults in the lighting system are not reported automatically but rely on either the citizen who reports faults or the regular inspections that consume resources. Light points that are neither reported for error nor inspected thus risk not being repaired. This can affect traffic safety and the feeling of security among citizens. Detecting and reporting errors in bright spots automatically and in real time facilitates and improves for citizens and maintenance contractors.
After the workshop, valuable insights were taken considered, and based on the insights, abstract solutions were iterated. The solutions are evaluated and assessed based on feasibility, suitability, and whether they meet the problem and goal definition.
The potential for the solution was assumed to be rational and reasonable. This made it possible for the evaluation of the methodology and that the project could proceed even if the solution could have lacked potential.
4.1. PoC Design
Figure 5 shows the design of the system architecture. The components were selected based on availability, price, and time from start to possible commissioning. Figure 6 shows the network topology and how the components communicate with each other.
4.2. Build
The development of the hardware and the software took place in parallel. For the management of clients, sensor data, and storage of data, several ancillary services in the cloud service Microsoft Azure were used. These services were Azure App Services and Azure IoT hub. The network between the services is shown in Figure 6. The developed sensor node and gateway are shown in Figure 7. The LED driver is controlled pulse-width modulation (PWM). In the process of the LED lighting system, the pulse-width modulation alternates between 0 and 1 for altering the light dim output. Figure 8 shows the LED connecter for the sensor node, and Figure 9 shows pulse-width modulation variations corresponding to the digital signal values [24].
4.3. PoC Design Evaluation
We give the evaluation outcomes in three ways in our proposed research: (1) error simulation, (2) PoC Design process evaluation summary, and (3) power consumption optimization. Route guidance is provided via Google navigation, and the status is checked following each order. For simulating testing, each IoT device is certified to perform appropriately and under GPS navigation.
The purpose of the proposed methodology is to improve the development of an IoT-PoC and increase the number of successful IoT initiatives. The interviews revealed that successful IoT initiatives have their basis in solving a problem or fulfilling a need that is linked to the business benefits for the customer. A PoC that is not rooted in a problem or need should thus not be developed to avoid unnecessary resource consumption. To clarify the analysis of the methodology and the result, the discussion is divided into the phases of the PoC Design methodology. In our research, simulated testing is conducted for a bright spot regarding error detection. For a quantitative evaluation of the developed IoT-PoC, simulated errors were performed at a bright spot. The results of this evaluation are presented in Table 1.
A qualitative evaluation of the first design was carried out according to selenium testing [25]. In the evaluation, discussions were held about the choice of system architecture, network topology, and a demonstration where the errors were simulated and all were detected. Table 2 summarizes the evaluation results for street lighting connected scenarios mentioned in the design process.
According to the study, because almost all tasks, such as power outages, error simulation, GPS navigation, and today’s program reception, are highly routine, unnecessary, and undesirable, it is difficult to expect the highest efficiency when which is delivered or controlled automatically, i.e., remote form. It is adequate and more tailored to meet your expectations based on the selected acclamations. The investigational outcome reveals that a particular advantage can be obtained in the meantime it combines routine monotonous activities in one task that dominates. It is engendered by identifying the position of the bright spot, and the other tasks onstage are performed by the design and flawless. For the next iteration and to further develop the PoC in line with customer and market, the lessons learned from the evaluation were used. The lessons were changes and additions that are given in Table 2. The additions were deemed advantages for use in future projects.
4.3.1. Smart Street Lighting Power Consumption
In the third case, we discover that it is beneficial to apply the control instructions by examining the database obtained from the AWS server. It anticipates individual preferences and produces helpful applications in a variety of ways as it gathers information from bright spots. In this study, a restricted number of bright spots are integrated and presented to critical activities that are performed automatically without any request, even if they are not repeated. However, in specific circumstances, as many devices as feasible can be integrated. To do this, the smart light platform must be built to allow extension to provide customization for various kinds of equipment handling digital data. Without any error occurring, all the control instructions need to be executed, with approved authorization and at appropriate intervals [26]. Otherwise, people would be irritated and will stop using these services. The test was carried out for the smart street light prototype system. The analysis was carried out on regular and holiday days.
4.3.2. Normal Day
This section looks at how street lights are used on a normal day. It is assumed that, on a normal day, the movement of the vehicle is high and the percentage of the IoT-enabled street light usage will be optimized using sensors. The power usage for the PoC Design street light on regular days is calculated using these data. Using the PoC Design street light system, 44.84 percent of electricity may be saved throughout the usual day.
4.3.3. During Holidays
This section looks at how street lights are used during the holidays. It is assumed that, on holidays, the movement of the vehicle is low and the percentage of the IoT-enabled street light usage will be more. According to the data gathered, the energy utilization for the PoC Design street light during holidays is 32.22 percent. During the holidays, there is an increase in energy usage. Table 3 shows the percentage power saving analyzed using PoC Design.
5. Conclusion
Since the year 2000, urbanization has gained much importance, and smart cities being one of the most pressing concerns. The backbone of future smart cities is smart street lighting. By connecting each lighting pole to a larger network link, each light becomes IoT-ready and serves as a gateway for larger smart cities. The literature study in the field of development of IoT systems did not provide a clear methodology that describes an entire process for the development of an IoT-PoC. However, these methodologies from the literature study contribute insights to parts of the development process for an IoT-PoC. The interviews with representatives from three different consulting companies working with IoT projects show similarities but also differences in their methodologies. The consulting companies' methodologies are all contributing to the design of the PoC Design methodology.
The results of the case study, where the PoC Design methodology is applied to a project, show that the PoC Design methodology overall works well for the development of an IoT-PoC. All stages of the PoC Design methodology help secure business benefits for an IoT project and to avoid unnecessary use of resources. According to consulting companies, these are key criteria for a successful IoT project. Avoiding unnecessary resource use has positive effects on customers, consulting companies, and society as a whole. According to Cisco Systems, only 26% of IoT initiatives are considered successful [4]. Following the PoC Design methodology, therefore, according to the results of the study, wanting to contribute to improving the statistics, the percentage of energy savings is 32% during holidays and 45% during normal days. From Table 1, according to the error simulation performed on 150 errors, our proposed PoC Design method has attained 100% accuracy in detecting the errors.
5.1. Future Work
The PoC Design methodology focuses on which steps ensure the greatest business benefit by identifying problems and solutions for customers from a technical and business perspective. This study ignores the cultural perspective of projects. Therefore, it may be interesting to examine this perspective in the future concerning the PoC Design methodology. The difference between applying strict time frames or not for the project was also not explored in this study. The reason for choosing strict time frames was instead based on an article about the effects time frames have on people, but not on projects as a whole. The study has evaluated the PoC Design methodology in a case study where its results have been discussed. There has been difficulty in comparing the result with another comparable result. To compare the PoC Design methodology with other methodologies, a proposal for future studies is to carry out two projects: one with the PoC Design methodology and one with another methodology.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request ([email protected]).
Conflicts of Interest
The authors declare that they have no conflicts of interest to report regarding the present study.
Authors’ Contributions
K. Prasanna contributed to conceptualization, data curation, formal analysis, methodology, writing original draft, and software development. Kadiyala Ramana contributed to data curation, writing original draft, investigation, collecting resources, study validation, and software development. Gaurav Dhiman carried out study supervision, reviewed and edited the manuscript, and contributed to project administration and visualization. Kautish Sandeep carried out study supervision, reviewed and edited the manuscript, obtained funding, and contributed to study visualization. V. Deeban Chakravarthy contributed to visualization, investigation, formal analysis, and software development.