# DIKWP-Driven Artificial Consciousness for IoT-Enabled Smart Healthcare Systems
## 6 Experimental Results
### Comparative Scenario Analysis  
We further evaluated the system's performance under different operational scenarios and configuration settings to understand how context and parameter tuning affect outcomes. In particular, we compare (a) daytime vs. nighttime monitoring, (b) high-sensitivity vs. low-sensitivity configurations, and (c) different alert threshold levels. The results are presented in tables with side-by-side comparisons for each condition. 1. Daytime vs. Nighttime Monitoring  
These scenarios reflect how the system performs in an active daytime environment (with more movement and potential noise) versus a relatively quiet night environment. We simulated \"daytime\" conditions by introducing more motion artifacts and variability into the sensor data (mimicking a user's daily activities), whereas \"nighttime\" data had steadier vitals and minimal motion noise (mimicking a resting sleeper). As shown in Table 6, the system maintained a high event detection rate in both cases (~95% recall for a set of test health events both day and night). However, the false alarm rate dropped from 5% in daytime to 2% at night, presumably because the calmer nighttime data had fewer spurious fluctuations that could be misinterpreted as events. Consequently, the precision of alerts at night was higher. The detection latency was slightly better at night (average ~1.8 s) than in the day (~2.0 s), since less noise meant the system could confirm anomalies slightly faster with fewer redundant checks. We also observed that the system's average power consumption was marginally lower at night, as the DIKWP agent spent less effort handling noise or repeated triggers--e.g., the processing and communication overhead from false positives was lower. From a user perspective, nighttime alerts were infrequent but highly accurate, which is important because any false alarm during sleep is particularly  
Figure 8: Example event trace over time for an arrhythmia scenario. disruptive. Overall, this comparison suggests the DIKWP-based monitor is robust across daily conditions, with a tendency toward higher precision in low-noise settings. During nighttime, the system yields very few false alarms, aligning with the need to avoid alarm fatigue during sleep. In daytime, although slightly more false positives occur due to motion-induced noise, the performance remains within acceptable bounds. 2. High vs. Low Sensitivity Configurations  
We evaluated two configuration extremes to explore the trade-off between sensitivity and specificity. In a high-sensitivity configuration, the system is tuned to detect even mild or early signs of anomalies (e.g., using a lower threshold for heart rate deviation or a more permissive anomaly detector). This setting prioritizes catching all possible events at the risk of more false positives. In the low-sensitivity configuration, the criteria for triggering an alert are stricter (higher thresholds, requiring more significant deviation or longer anomaly duration), which reduces false alarms but may miss subtle events. We applied both configurations to the same dataset of simulated health events. Table 7 summarizes the outcomes. As expected, the high-sensitivity mode achieved a very high detection rate (recall \(\sim\)99%), catching virtually every anomalous event in the data. However, this came at the cost of a false alarm rate of about 10%, higher than our baseline scenario--meaning some normal fluctuations were incorrectly flagged. The average detection latency in high-sensitivity mode was slightly lower (\(\sim\)1.5 s), since the system would alarm on the first sign of anomaly without waiting for further confirmation. The low-sensitivity mode showed the opposite pattern: the detection rate dropped to 90% (a few minor events went undetected), but the false alarm rate improved to only 1%, indicating very few spurious alerts. Latency in low-sensitivity mode was a bit higher (\(\sim\)3.0 s) because the system waited longer (for more evidence of a true issue) before alerting.