## 5 Use-Case: Energy Imbalance Billing at the Primary Substation
### ESP/CSP-Based Energy Imbalance Billing  
The PriST PGDIN performs the energy imbalance billing check according to a pre-established frequency (daily or more often). In order to ensure that this process is carried out within at least quasi real-time constraints, in our architecture this task is performed by the ESP/CEP engine. DDS offers real-time communication and so do a number of CEP engines (see [43] for real-time performance tests of Exper, an open-source CEP). The third member of the triad needed to guarantee strict real-time response time, the PGDINs, depend on the hardware platform in which they will be actually deployed (this information will be disclosed when the project's industrial partners present the products designed within the project). So far, the knowledge processing algorithms (especially those dealing that deal with RDF triplets handling) are the main bottleneck that force to offer _only_ quasi real-time. First, the PriST PGDIN applies an event processing network (EPN) as follows (see in Listing 1 this EPN for an Oracle EP): first, it identifies the events (including those already cached) and issues a new composite event joining the simple ones. To this end, the PriST PGDIN has to discover the identity of the PGDINs susceptible to send information on this topic. To this end, as introduced in Section 4.3, it infers from the ontology profile the electric assets physically connected to the one(s) it controls. Then, it asks in the DDS bus who is the PGDIN managing that/those asset(s) (note that these tasks are carried out only once and thereafter, the information is retrieved directly from the knowledge database) and, finally, it selects a subscription of the event through the DDS bus. Second, the PriST applies an EQL (Event Query Language) query to validate the composite event (EQL is similar to SQL but is vendor-dependent, so each CEP/ESP engine presents a different specification depending on the vendor). The information of the single events is published by the corresponding SecST PGDINs encapsulated as cim:Readings into a Plain Old Java Object (POJO), and is injected into the ESP/CEP engine through the DDS connector. Thus, the PriST PGDIN, previously subscribed, will receive the information upon publishing. As one may think, there is neither order nor orchestration on publishing this measurement values. Therefore,the PriST PGDIN actually receives a stream of events that must be either processed directly or stored in the cache to be analysed later. Moreover, there are a number of basic SQL (Structured Query Language, for managing data in Relational Database Management Systems) concepts (e.g., aggregation through grouping, filtering or correlation through joints) that can be carried out. Unfortunately, EQL is not flexible enough and cannot apply any semantic property as we will do in the next use case (note that in Listing 1 concepts such as MeterReadings are not expressed according to the unified data model described in Section 4.1 and, thus, no name-space is cited). Finally, there is a rule that validates that the aggregated and the retrieved own values match. Hence, if this constraint is not fulfilled, the PriST PGDIN as mentioned above will react immediately by injecting a new alarm event into the CEP/ESP bus, which will be then processed either by the same PGDIN or by its predecessors.