## 4 System Architecture
### Communication and Data Exchange  
Sharing the information in this architecture is achieved through the DDS bus and following a _publish/subscribe_ communication paradigm. Therefore, PGDINs select the information susceptible to be consulted by the rest of the network components and publish it. Interested peers only have to use the subscribe mechanism offered by DDS and they will receive promptly upcoming information as soon as it is generated. Eventually, one PGDIN may require another to publish certain information but, as a rule, depending on their physical location and task, they all share a predefined set of data-points. Still, there are some legacy applications and systems that are not compliant with this paradigm and offer their information on a request-response basis (for instance through a Service-Oriented Architecture interface). This possibility is not mandatory and is reserved for PGDINs with Internet connection (e.g., PGDINs at the utility, carrying out business process involving PGDINs-network-generated information and additional information from the aforementioned legacy systems). In any case, the shared information ranges from _usual_ (e.g., without time constraints such as historical load data, active and reactive power consumption in different time horizons) to _urgent_ (e.g., presenting strict real-time requirements such as alarms from the ESP/CEP engine, security sensor data from primary or secondary substations, _etc._) DDS enables sharing information in different time frames through the same bus due to its widely-parameterisable QoS configuration.  
The collaboration between PGDINs helps to resolve specific situations that, for instance, require comparing or combining data from several intelligent nodes. Furthermore, these interactions can also be understood from an interoperability perspective problem in which all the PGDINs own a common ontology. Figure 3 illustrates the proposed architecture, focusing on the deployment of the PGDINs and the communication technologies.  
The flow of events orchestrated by the node occurs as follows: field events (alarms, measurements, _etc._) potentially produced by the various devices are grouped and routed using protocols adapters and the DDS bus, then converted to Java objects, and finally injected into an engine for event processing. This engine is responsible for detecting patterns of unusual conditions such as sudden changes in measured quantities, cutting conditions or supply problems. Eventually, intelligent decisions about these  
Figure 3: PGDINs involved in the energy imbalance billing use-case.  
situations require the evaluation of rules and semantically rich query execution. Additionally, the event processing engine is responsible for feeding information repositories based on two technologies: first, a distributed cache of objects that represent the state of configuration and real-time information on devices (\"Distributed Cache\" in Figure 1), and second, a semantic database that stores information on events that must be addressed through collaboration with other agents or semantic inference (\"RDF-DB\", or database of RDF triplets, in Figure 1).