# Rapid Prototyping of Multi-Functional Battery Energy Storage System Applications
## 3 Related Work and Background
### Research Needs and Requirements  
A previous study evaluates the efforts done to tackle the issues exposed in Section 2.3, resulting in the following four main requirements for this work:  
* _Alignment with Domain Standards (R1):_ An appropriate solution to model a multi-functional BESS should benefit from the extensive data models provided by the mentioned standards in Section 3.1.
* _Common Ontology for Multi-Functional BESS (R2):_ A comparison of smart grid control development approaches was carried out in Section 3.2. This demonstrates a lack of one approach that fully covers the function and information domains during the design phase. What is not covered is a method to handle a high amount of data and also a vocabulary for a common understanding of EMS applications. The characterization of EMS behavior is dismissed since it is completely covered by other approaches (e.g., MATLAB, IEC 61499). Attempts to propose a pattern for controlstrategies were done in SGAM. However, it needs to be enlarged in order to cover features mainly important to BESS use cases. An ontology is a good candidate to integrate the knowledge from EMS as highlighted in Section 3.3. Thereby, R2 searches for an ontology focused on multi-functional BESS and also for mechanisms to achieve a population of it. The resulting ontology that represents and describes EMS should guide control engineers during the design stage. A derived benefit from this is to enable the access of EMS capabilities to external systems (e.g., EMO).
* _Identification of Conflicts and Inconsistencies (R3)_: An early diagnosis of potential conflicts within EMS corresponds to the overlapping issue in Section 2.3. That topic was tackled in [37], as a result a classification of conflicts (Conflict \(C_{I}-C_{VI}\)) and its modeling by ontologies is achieved. In addition to this, the study formally defines DL queries to identify the classified conflicts and a handling solution per conflict type is exposed and recommended. The outcomes from [37] should be implemented in a whole solution that supports the design of EMS.
* _Generation of Software Artifacts (R4)_: One of the issues highlighted in Section 2.3 requires implementing EMS applications into different power system tools (i.e., design, emulator). Thereby, the generation of software artifacts at the proof-of-concept and implementation phase should be assured. MDE invokes two types of transformations: Model-to-model (M2M) and Model-to-text (M2T) transformations by the setting up of transformation rules. Both transformations should be carried out at the design stage, and this would improve the rapidity and interoperability of the EMS engineering process. The generation of code and models from an EMS platform-independent model is part of the requirement R4.  
In summary, current efforts to face the issues encountered during the EMS development process were evaluated. Thereby, current standards for the power utility automation domain are studied (e.g., IEC 61850). As a result, R1 motivates the use of existent information models. Moreover, approaches that support the whole chain of the development process (e.g., SGAM, PSAL) are compared to realize the specific points that need to be targeted to address the complexity issue. This results in R2, and it searches for a common vocabulary for BESS UCs. Afterwards, the overlapping within a multi-functional BESS motivates the assessment of ontologies in smart grids. That topic was already addressed in [38]. Hence, R3 envisages the implementation of the outcomes from the mentioned study in EMSOnto. The interoperability issue is tackled by model-driven engineering techniques, and this is conceptualized in R4. As a result, the basis for the conception of EMSOnto are formulated under requirements R1-R4.