# DIKWP-Driven Artificial Consciousness for IoT-Enabled Smart Healthcare Systems
## 6 Experimental Results
### Simulated Data Examples and Event Traces  
To better illustrate how the DIKWP-based artificial consciousness operates with physiological data, we prepared simulated sensor data representing various typical scenarios in a healthcare IoT environment. We focused on two key biosignals--heart rate (HR) and respiration rate--as they are commonly monitored vital signs. The simulated time-series data were labeled to indicate different health conditions or signal statuses: normal conditions, an arrhythmia event, and sensor noise artifacts. Table 5 presents excerpts of these time-series examples with their associated condition labels. Note that Table 5 shows only representative segments of the simulated data for brevity, rather than the complete dataset. For clarity and completeness, a larger snapshot of the simulated sensor readings (covering an extended duration for each scenario) is provided in Appendix A, offering a more comprehensive view of the data collected in the simulated environment. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Metric** & **Value** & **Remarks** \\ \hline Detection latency per event & 2.1 s & Time from event occurrence to alert notification. \\ Energy consumption per inference & \textasci{}45 mJ & Measured on smartphone; low impact on battery life. \\ User satisfaction (alert relevance) & 4.3/5.0 & High relevance; few false alarms (\(n=10\) users sample) \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Additional performance metrics of the DIKWP-based smart healthcare system. In the normal scenario, the heart rate and respiration remain within stable ranges (e.g., HR in the low 70 s bpm and respiration around 16 breaths/min), reflecting a healthy resting state with only minor natural fluctuations. In contrast, the arrhythmia scenario shows an episode of irregular heart activity: prior to the event, readings are normal, but when the arrhythmia occurs, the heart rate exhibits sharp variability (e.g., spiking to 110 bpm then dropping to 65 bpm within seconds) and the respiration rate may increase due to physiological stress. These readings are labeled as \"Arrhythmia\" during the abnormal pattern. The noise scenario simulates spurious sensor readings--for example, a momentary zero or an impossibly high HR value (150 bpm)--which are labeled as \"Noise artifact,\" indicating they likely result from sensor error or motion artifact rather than a true physiological change. Such noisy data points need to be distinguished from true events by the system's reasoning module. The DIKWP-based reasoning agent processes these incoming data in real time, transforming Data \(\rightarrow\) Information \(\rightarrow\) Knowledge \(\rightarrow\) Wisdom \(\rightarrow\) Purpose in its cognitive pipeline. To demonstrate the system's behavior, Figure 8 provides an annotated event trace for an arrhythmia scenario using the above data. This trace shows a sequence of time-stamped sensor readings and the corresponding DIKWP-based reasoning outcomes at each step. At the start (time 0-2 s), the patient is in a normal state; the agent's inference component recognizes these readings as normal, and the reasoning module does not trigger any alert (Outcome: \"No alert--all vitals normal\"). As the arrhythmia begins (time 3-4 s), the heart rate deviates sharply from baseline. The system's inference step detects this anomaly (e.g., an irregular rhythm pattern), elevating the data to an information level event. The reasoning component then interprets this information in context--recognizing it as a potential arrhythmia health risk (transforming information into actionable knowledge/wisdom). Consequently, at time 4 s, the system issues an alert (Outcome: \"Alert: Arrhythmia detected\") via the communication module, fulfilling the Purpose aspect of DIKWP by taking action to notify the user/caregiver. The trace then shows the post-event period (time 5-6 s) where vitals return to normal; the agent correspondingly resolves the alert (Outcome: \"Recovery--alert cleared\").