# DIKWP-Driven Artificial Consciousness for IoT-Enabled Smart Healthcare Systems
## 5 Prototype Implementation
### Technologies and Tools  
Our implementation uses a combination of programming frameworks:  
* Hardware Simulation: We simulate wearable devices using a microcontroller emulator that generates data. For example, heart rate is simulated as a data stream (with baseline 70-80 bpm and occasional spikes for events). We also simulate an accelerometer data stream to detect falls (by generating a characteristic spike pattern when a \"fall\" occurs).
* Edge Agent: The edge intelligence is implemented as a Python 3.7.4 service running on a Raspberry Pi (for a real deployment, or simply on a PC in our tests). We chose Python because of its rich ecosystem for both IoT (libraries for MQTT, sensor reading) and AI (numpy, scikit-learn, etc.).
* Cloud Agent: Implemented as a Node.js application to illustrate cross-language interoperability (showing that one could implement edge in Python and cloud in  
Figure 6: Prototype interface of the DIKWP-driven smart healthcare system.  
another environment). The cloud agent subscribes to all patient topics (or multiple, in our test we just had one patient at a time). It stores incoming info in a simple database (SQLite for prototyping) and runs a global analysis periodically. For global analysis, we implemented a federated averaging of a hypothetical model parameter--specifically, each edge maintained a counter for anomalies detected and total monitoring time, which the cloud used to estimate an \"anomaly rate\" per patient and overall. This is trivial compared to real ML, but serves to show the concept. The cloud can then issue a command if a patient's anomaly rate is trending poorly (for instance, instruct edge to increase monitoring frequency).
* Semantic Task Orchestration: We created a small rule definition file (rules.dsl) that follows the patterns described. A parser script reads this and configures the rule engine on the edge. If we want to update rules at runtime, the cloud can send the new DSL snippet to the edge which the edge agent applies (in practice, our test just loads once at start or on command).
* User Interface: A simple web dashboard displays alerts and their explanations. When the edge agent issues an alert, it publishes not only the alert type but also a JSON with the DIKWP trail that led to it. For example: { _\"alert\": \"PossibleFall\"_, _\"visdom_reason\": \"fall_detected AND tachycardia\"_, _\"knowledge\": [\"fall_detected\": true, \"HR\": 140]_, _\"time\": \"2025-06-01T10:00:00Z\"_ } This is stored and the dashboard can show \"Alert: PossibleFall at 10:00--Reason: fall_detected AND tachycardia (HR = 140)\" to the user. This transparency is important for user trust.  
We note that due to resource constraints, certain components are simplified. The AC notion of concept space vs. semantic space (as in some DIKWP papers) is not explicitly separated in code; instead we combine semantic labeling with knowledge rules in one mechanism [52]. Also, the edge and device distinction was blurred in our prototype in the sense that we ran both simulated wearable and edge agent on the same machine for convenience, communicating via local network calls. In a real deployment, they would be separate physical devices communicating via Bluetooth or similar.