# Rapid Prototyping of Multi-Functional Battery Energy Storage System Applications
## 4 Application Development with the EMSOnto Approach
### Core EMS-Ontology Use Cases  
The core part of the EMSOnto approach as depicted in Figure 2 is based on the design of the EMS-\(TBox\). This involves a deep understanding of the EMS application itself, the services deployed within it, and the components controlled or monitored by the EMS. Because of that, an evaluation of services provided by the EMS is carried out. Those services are exemplified by use cases UC1-UC5 (already introduced in Table 1). From that, a pattern to guide the design of the EMS-\(Tbox\) is presented.  
Typically, an EMS application involves a main controller and its environment as shown in Figure 3. The controller \(K\) carries out the corresponding control and optimization functions. The EMS itself is focused on the provision of multiple services supported by a BESS (see UC1-UC5). Thus, many  
Figure 2: Overview of the EMSOnto framework and corresponding design and engineering process.  
services (\(Service_{1},\ldots,Service_{n}\)) may be embedded in \(K\). Each service follows specific control strategies. Hence, they need to measure states from the electrical process \(G\), composed by IED such as batteries, smart meters, photovoltaic generators, etc. Furthermore, services should receive setpoints (\(w_{1},\ldots,w_{n}\)) to regulate certain states of the electrical process (\(y\)). As a result of the regulation process, command values (\(u\)) are sent to \(G\). Those control values are taken into account by \(G\) as long as a setpoint (\(m\)) is available within IEDs. A similar occurrence is noted in the measurements \(f\). They are available only if the IEDs give access to their states (\(s\)). Besides the aforementioned values, a set of parameters within the controllers (\(K_{1},\ldots,K_{n}\)) defines the control behavior. For instance, the controller within UC1 (\(Q_{bat}=\alpha V_{pcc}+\beta\)) requires the setting up of \(\alpha\) and \(\beta\).  
Use cases UC1-UC5 are mapped into the control scheme presented in Figure 3 resulting in Table 3. This mapping validates the modelling of EMS by the previous mentioned information (i.e., \(w,Service,f\), etc.). Other elements to be considered in the modelling of EMS are systems that interact with EMS besides the process \(G\). The aforementioned use cases address services interacting with other stakeholders spread out in the distribution network (Distribution System Operator (DSO)) and the transmission network (Transmission System Operator (TSO)). In certain use cases, those systems, denoted by \(A\), require setting variables of \(K\) remotely (e.g., parameters). For instance, UC2 deploys within the controller \(K\) the logic \(P_{bat}=\gamma F_{grid}+\theta\). The charging of the battery (\(P_{bat}\)) may be configured remotely by the TSO by modifying the parameters \(\gamma\) and \(\theta\). Furthermore, case \(A\) needs to monitor values from \(K\), and the controller \(K\) should be capable of sending status values (\(s\)). At the same time, \(A\) would receive feedback (\(f\)) from \(K\). This leads to the conclusion that systems \(A,K\) and \(G\) share many similarities and can be represented under a common pattern composed of variables shown in Figure 3 and Table 3 (i.e., \(y,u,w,K,Service,\ldots\)).