# Rapid Prototyping of Multi-Functional Battery Energy Storage System Applications
## 5 Proof-of-Concept Evaluation
### Evaluation of Requirements and Open Issues  
EMSOnto is conceived under the fulfillment of requirements R1-R4. As a result, this approach claims to support control engineers during the design of EMS applications. In order to demonstrate and evaluate it, a use case example (CEMS) is designed and validated. This section analyzes how far the initial stated requirements (R1-R4) were satisfied. **Repository based on SGAM and IEC 61850**. R1 requires benefitting from existent smart grid data models. Hence, EMS-ontology is conceived under the standards IEC 61850 and SGAM. This OWL ontology defines the structure of spreadsheet templates, which facilitate the creation of pre-defined models (e.g., battery inverter [19] and frequency-watt [12]) to be stored within the IED and use case repository. The referred repository is built and available to the control engineer to start the design of EMS applications. In the CEMS example, the PUC(Linear-Control) uses knowledge from a FWHZ Logical Node accelerating the collection of CEMS data. **EMS-ontology and EMS-templates. ** R2 searches for an ontology that reflects a common understanding of multi-functional BESS. Thereby, a pattern that models different BESS use cases (UC1-UC5) is established resulting in EMS-ontology. The proposed OWL ontology was used to detail functions, parameters and information flows within the CEMS use case. This demonstrates that roles and concepts defined in the scope of EMS-ontology are appropriate for EMS description. Population of the ontology is achieved by filling out EMS-templates. Control engineers became familiar with this method quite fast, demonstrating that it is a good practice in gathering and documenting of data at the design phase. A feature not supported by the approaches presented in Table 2.  
Figure 17: Real measurements (\(P_{bat}\), \(SoC_{bat}\)) and simulated values to perform FW and SelfC. A benefit derived from ontologies is the extraction of data from \(ABox\) by means of queries. In that sense, once the filling process of EMS-templates is complete, a set of reports to determine EMS functional capabilities can be queried by an external system (e.g., EMO) (see Table 9). However, it is worth noting that information in the design phase may evolve during the proof-of-concept phase (e.g., a signal \(fd\_FW\_Ena\) was included during the validation of the CEMS). Hence, the final state of the EMS knowledge may differ from the information gathered at design time. Thus, a reverse engineering process [49] between the design and proof-of-concept stage is suggested to keep EMS data updated. As mentioned before, the conception of EMS-ontology is aligned to the broadly recognized SGAM and IEC 61850 data models. Nevertheless, interoperability between EMSOnto and information models such as CIM and OPC UA should also be considered since they are strongly recommended in the semantics for smart grids [50]. **Detection and Handling of Conflicts. ** R3 requires the implementation of the study [38] to support the design of EMS. To achieve the aforementioned, EMS-ontology and the OWL ontology proposed in [38] are aligned. Furthermore, EMS-templates are suggested to gather information mainly important for conflict identification. As a consequence, an error-free EMS-\(ABox\) is achieved before starting any implementation of the control applications. This was exemplified by the CEMS, where conflicts \(C_{I}\) and \(C_{V}\) were detected and the handling solution proposed by EMSOnto was considered in order to correct the CEMS design. Nevertheless, other kinds of inconsistencies not covered by EMSOnto may be raised during the EMS operation such as an erroneous sensor (i.e., smart meter), a measurement signal with a low sampling rate or the setting up of out-of-range values into the BESS inverter. Those inconsistencies were not considered by EMSOnto, in order to detect them an observation of states over time is necessary. This would require bringing the concept of temporal logic and concrete logic into description logic as performed in [51].