## 6 Implementation
### Performance Assessment  
CompoSecReasoner is evaluated under a testbed. The user administrates the system's SPD via an Android application in a smart phone (Android 5.0 KNOX OS, 16 GB RAM, 2.5 GHz quad-core CPU, 4G, Wi-Fi) which connects the home's LAN wirelessly with WiFi. PEP and the controlling software of the electric device are installed in the BeagleBones (Ubuntu Linux OS, 256 MB RAM, 720 MHz ARM Cortex-A8 processor, USD-WiFi). We use two BeagleBone devices that connect the LAN wirelessly with the USB-WiFi. The BeagleBones are also supplied with a weather cape-for the measurement of environmental parameters, like temperature, ambient light, and humidity; and a battery cape-for power supply. The BeagleBoard manages a surveillance USB-camera and is plugged to the home's power supply. CompoSecReasoner and PBAC run on a laptop (Windows 8.1 Pro OS, 8 GB RAM, 2.1 GHz Inter Core i-7 CPU, WiFi). The testbed and demo settings are depicted in Figure 7.  
We utilize the smart phone application to run the benchmark where the user triggers SPD changes on the home equipment, such as the SPD configurations of PBAC and IPsec. We assess the changes' impact on the computational complexity of CompoSecReasoner as well as the overall system's responsiveness.  
Figure 6: Composition of two smart buildings.  
Figure 7: Smart home equipment. (**A**) BeagleBone with weather and battery capes, USB-WiFi, and SD memory card. (**B**) BeagleBoard with USB-Camera, power supply, USB-WiFi, and SD memory card. (**C**) Android smart phone device with the user’s smart home application.  
The RETE algorithm (one of the main and widely-utilized pattern matching algorithms for implementing rule-based systems) [79] is utilized internally by JESS, achieving optimized speed and forming a quite efficient pattern-matching engine. The CompoSecReasoner's reasoning theory for the smart home application requires around 400 facts and 30 rules. The whole reasoning framework need on average 1.6 s, 45 MB RAM, and 1.87 MB for the code. Nevertheless, this is expected to be done once, when an agent is started. After that, when the rule engine is up and running, it takes around 0.002 s to process a theory with a few hundreds of facts [80]. Therefore, this is the actual real-time delay for applications. The code size is not affected while the additional RAM is minimal.  
The most notable performance factor is the response time that the user experiences when he/she retrieves information or when SPD changes are happening. The overall delay of the concurrent benchmark requests is depicted in Figure 8. Spikes reflect the SPD changes (e.g., incoming SA requests, system configuration, and notification of the SA when a change is completed). Such changes produce considerable delay, however, in normal operation the system is set in a specific configuration for most of the time and changes are expected to be rare. Nonetheless, the framework exhibits acceptable delay, even for a real-time environment.  
Regarding scalability, the reasoning complexity is affected by: (i) the number of rules (\(R\)), (ii) the number of facts (\(F\)) on the working memory, as well as, (iii) the average patterns per rule left-hand-side (\(P\)). The total complexity is linearly influenced by the size of the working memory and is of the order of \(O(RFP)\). In CompoSecReasoner, the number of the theory rules (\(R\)) is very low, i.e., around 30 rules the smart home scenario. Also, unique identifiers are assigned to every entity and the upcoming events influence specifically denoted parameters, thus, the pattern-matching ratio (\(P\)) is also low and in the magnitude of one to three. Actually, scalability is influenced mostly from the facts' amount (\(F\)). In this demo, each system component takes around 5-10 facts to be defined, producing a low computational overhead (in the nanosecond range) and less than 40 extra bytes in RAM for the SPD agent.