## 3 System Architecture  
According to the results of the previous system [15], the main CBR system architecture and its four main steps are unchanged, but two optimization steps for calculating the similarity of the cases are added to more clearly illustrate the relevant calculation procedures, which are illustrated later. Figure 7 presents the framework of this OntoCBRA system. Here, Ontological Database Access Cases (ODAC) are mainly periodically generated by the Historical Information of WIAS and the case generator under the ontology database index of the system. If the directive is whether there is a CBR solution, then the function Case Retrieval will launch ODAC under the ontology database index to accurately and effectively retrieve the same or similar cases. These cases have their similarity calculated based on the retrieved cases. Identical cases will be directly returned to the Ubi-IA; those that are not identical, but meet the standard of trimming (the threshold set by this system), will pass onward to case trimming for further processing. After undergoing trimming, the most appropriate solution comes out and is transferred to the interface agent system for reference. If the user is satisfied with the solution, then this solution will enter into the step of case retainer; otherwise, it will be discarded directly. Finally, the system decides whether the trimmed case should be stored based on case similarity  
Figure 6: Framework of the WIAS System. (beyond the threshold set by this system) and then restores it to ODAC under the system ontology index. In addition, ODAC relies on a case monitor to provide case information, which can become the materials for OntoDMA to establish prediction rules [14]. The source of the training materials for this case-based reasoning was the sensing data of electrical devices operating in a specific energy-saving monitoring environment and was sent in relay transmission. These sensing data was transmitted to Interface Agent at regular intervals, and the received data was stored in the cloud database via the services offered by WIAS. The cases were generated by the Case Monitor of WIAS by transforming the huge original data into information with semantic meaning. At the end, this information was summarized into cases in the case base, which were generated by the accumulation of transformational processing experiences. In other words, the knowledge content of the cases in the energy-saving information system was planned to that of a description that converts raw data to a semantic meaning for a specific time, area type, area size, measurement and control (MAC: Media Access Control Address) type and sensing data. As mentioned earlier, the case-based reasoning is a technique based on past experiences and successful cases to solve a current problem. Therefore, this study defined a case as the most common information in a given period and its corresponding energy-saving operational mode. In other words, it is the most stable energy-saving solution in the monitoring environment. Figure 8 shows the concept of case generation, for which its trigger was the case monitor of OntoCBRA, which can communicate with WIAS. Its periodic off-line operation can send historical information of the cloud database to OntoCBRA as the material for case generation. However, the original case shown in Figure 8 cannot directly be used in various energy-saving operational modes. Hence, it was necessary to convert the case into an appropriate semantic case in accordance with the corresponding sensor category table, so as to apply it to most energy-saving case-based reasoning mechanisms. The practice example of a case generation is shown as Figure 9[20]. Figure 9 presents a complete case content, including the start day and time, end day and time, area type name, area size, measurement and control (MAC) type name, and sensing data.