# Rapid Prototyping of Multi-Functional Battery Energy Storage System Applications
## 4 Application Development with the EMSOnto Approach
### Templates for Application Design  
This section addresses requirement R2. Thereby, a mechanism to instantiate the previous introduced EMS-\(TBox\) is proposed, resulting in the realization of the EMS-\(ABox\). In order to provide the necessary information about the EMS, EMSOnto proposes the use of EMS-templates, a set of spreadsheets providing an environment for collecting and storing EMS-application related data. In this context, the usability of those templates is demonstrated by considering use case UC5 as an example. The structure of UC5 is represented in Table 5. From there, the following knowledge is available: A System\((Sys)\) contains four applications: Application\(\{\mathit{Battery},\mathit{HouseHold},\mathit{Meter},\mathit{EMS}\}\). In addition to that, an application type is conferred to them by instantiating the role hasType. Hence, hasType \(\{(\mathit{Battery},\mathit{BESS}),(\mathit{HouseHold},\mathit{Load}),\dots\}\). This allows for importing models already defined within the IED repository such as BESS, Meter, Load. The Application\((\mathit{EMS})\) requires providing three services that are represented under HLUC\(\{\mathit{VoltageCtr},\mathit{FW},\mathit{SelfC}\}\), the description of them is given in Table 5. Sub-concepts of HLUC (e.g., PQ, PS) are introduced to classify the services, hence the definition of hasType\(\{(\mathit{VoltageCtr},\mathit{PQ}),(\mathit{FW},\mathit{PS}),(\mathit{SelfC}, \mathit{MSC})\}\). Furthermore, an extended specification of functions within HLUC are given by the role hasPUC as follows hasPUC\(\{(\mathit{VoltageCtr},\mathit{PIControl}),(\mathit{FW},\mathit{K1}),(\mathit{SelfC}, \mathit{K2})\}\). The first pair represents the assertion: an HLUC called \(VoltageCtr\) contains a PUC called \(PIControl\) (i.e., PI controller). The same is expected for the other pairs. Further details of an HLUC and PUC are hereinafter given. The concept ParamUC suggests parameters for a generic UC (PUC or HLUC). Thereby, the inheritance of a generic UC by the previously defined HLUC  such as \(VoltageCtr\) would generate a list of attached parameters. As a result, the inference of the following assertions is achieved: Priority\((\mathit{prt})\), UCSoC\((\mathit{SoC})\) and hasParameter\(\{(\mathit{VoltageCtr},\mathit{prt}),(VoltageCtr,\mathit{SoC})\}\). The role hasParameter  represents a sub-role of hasVariable  having as a range the concept Param. The priority and SoC assigned to \(VoltageCtr\) are represented by Priority\((\mathit{prt})\) and UCSoC\((\mathit{SoC})\), respectively (see Table 6). Other parameters were also generated, but not presented in the table. A PUC usually needs to read measurement values from a process \((G)\), and, according to stipulated references, a control algorithm is carried out and control commands are sent back to \(G\). Bringing this to the UC5 example, a PI controller searches for the control of the voltage deviation at the PCC point (i.e., \(\delta V\)). To this end, the voltage of the PCC point \((\mathit{fd\_Vpcc})\) is measured and retrieved from a meter. Additionally, a control signal is sent to charge or discharge the battery \((\mathit{ct\_Qbut})\). Formatting those assertions according to the \(ABox\) syntax produces the following instantiations: hasControl\((PIControl,\mathit{ct\_Qbut})\), Control\((\mathit{ct\_Qbut})\), hasFeedback\((PIControl,\mathit{fd\_Vpcc})\) and Feedback\((\mathit{fd\_Vpcc})\). The role hasControl was introduced in Table 4, and a similar logic applies for hasFeedback, but having as range the concept Feedback. Table 7 shows the EMS-template to gather the aforementioned knowledge, and a detail of variables' attributes is also exposed.