# Rapid Prototyping of Multi-Functional Battery Energy Storage System Applications
## 5 Proof-of-Concept Evaluation
### Laboratory Implementation and Results  
The main objective of the laboratory implementation is to validate the executable software artifacts generated by EMSOnto and also to evaluate the benefits and limitations of EMSOnto during the proof-of-concept with real hardware devices. It is important to highlight that performance of control strategies (HLUC {SelfC, FW}) is not the main focus. A representation of the laboratory setup is illustrated in Figure 15. In order to keep a simplicity in the validation experiments, only the battery and battery inverter are represented by real hardware. In this context, a Tesla Powerwall and Sunny boy storage 2.5 are employed. The other components such as smart meter, PV generator, and loads are simulated within the power system emulator (Simulink/MATLAB) as well as the control strategies. The battery inverter communicates battery status (\(SoC_{bat},P_{bat}\)) by Modbus TCP/IP. The setting up of active power within the battery (\(P_{ref}\)) is done also by Modbus TCP/IP through the Sunny Home  
Figure 14: Offline simulation of the CEMS use case to achieve FW and SelfC. Figure 13: Software artifacts generated to be loaded within the power system emulator. (**a**) Simulink model generated; (**b**) CI function code generated. Manager, a control center for energy management. An interface between the power system emulator and the real hardware is needed to get and set data. Thereby, a Java program that carries out two Modbus clients and a MATLAB API is implemented. Modbus clients are configured to exchange data with the real devices. In turn, a library that enables Java programs to pass data from MATLAB to Java and vice versa supports the communication between the Java program and the Simulink model (CEMS). The hardware used in the laboratory setup is shown in Figure 16.  
The results obtained from the laboratory tests are shown in Figure 17. In order to show the behavior of CEMS, a specific frequency profile with over-frequency occurrences is built. The FW mode parameters are set to \(ECPNomHz=50\), \(DeltaHzStr=0.3\) and \(HzStop=0.1\). As a consequence, as soon as the frequency exceeds 50.3 Hz (\(ECPNomHz+DeltaHzStr\)), the Tesla Powerwall starts taking power from the utility grid. The active power charged into the Tesla battery depends linearly on the frequency values. This dynamic continues until the battery reaches its technical limitations at 2.5 kW (Sunny boy storage 2.5 supports a maximum charge of 2.5 kW). The values of 50.3 Hz and 50.1 Hz are represented by magenta and black dashed lines, respectively. FW mode is not requested more when frequency gets lower than 50.1 Hz (\(ECPNomHz+HzStop\)). Thereby, at 40,640 s, the FW mode is deactivated and self-consumption conducts the battery behavior. Hence, a PI control drives the value of \(P_{grid}\) towards zero. As mentioned before, only the battery is considered as real-device. Thus, \(P_{bat}\) and \(SoC_{bat}\) are real-values, and other values such as \(P_{load},P_{pv},P_{grid},F_{grid}\) were simulated. Communication delays and the time needed by the battery to provide the expected setpoint (\(P_{ref}\)) were considered in the synchronization between the Java program, the Simulink model and the real devices. Figure 16: Laboratory setup with the Tesla Powerwall and the Sunny boy storage 2.5. Figure 15: Laboratory setup for the validation of CEMS use case. The lab tests point out the benefits of EMSOnto at the proof-of-concept stage and motivate the extension of EMSOnto features. In that sense, benefits lie in the formal structure behind a UC representation. Thereby, the parameters such as \(HzStop\) and \(DeltaHzStr\) to be tuned within use cases were rapidly identified. On the other hand, conception of EMSOnto tackles information and function domain but not communication domain, which should be also supported. In that sense, manual work performed by control engineers to implement communication interfaces may be reduced by extending EMSOnto.