# Rapid Prototyping of Multi-Functional Battery Energy Storage System Applications
## 5 Proof-of-Concept Evaluation
### Realized Development Example
#### 5.2.4 Step 4: Customization of the Software Artifacts  
The knowledge derived from Steps 1-3 is transformed into software artifacts important for the validation of EMS. This is achieved in Step 4 by performing model-driven engineering techniques. The proof-of-concept of the CEMS is implemented in MATLAB/Simulink. A simulink model supports a block diagram representation, code generation, simulation of dynamic systems and customized block libraries. In turn, MATLAB provides the development of algorithms in textual programming form. The EMS-templates contain information about the CEMS structure, which is transformed into block diagrams within a Simulink model. This is reached by a set of transformation rules implemented in Atlas Transformation Language (ATL) and Eclipse Modeling Framework (EMF). EMF implements the key aspects of MDE practices by exploiting the facilities provided by Eclipse tools. Furthermore, the EMS-\(ABox\) being in RDF format, a conversion from RDF into a format to be processed and understood by EMF is required, and this is reached by employing the EMFTriple project. As a sequel, a transformation from the EMF model into a MATLAB/Simulink model (M2T) is automatically generated by the Massif framework for Eclipse, resulting in the model depicted in Figure 11, which was tailored and customized by the control engineer. A matching between knowledge regarding EMS structure in Table 10 and the Simulink/model is resulted. An extra amount of work realized by the control engineer is the design of control strategies. The behavior to be performed within PUC[Linear-Control, Limit_SoC,...] is not considered within the EMS-templates, and this is carried out in MATLAB/Simulink by customized block libraries and MATLAB-scripts. For instance, PUC(Linear-Control) is performed by a state-flow diagram in a Simulink model. As previously stated, PUC(Linear-Control) follows the control behavior defined in the Italian standard [48]. The mechanisms to be followed due to under-frequency events are illustrated in Figure 12. When the event \([ECPNonHz-Fgrid>=DeltaHzStr]\) takes place, active power is injected into the grid. Power injected depends linearly on the frequency, and it is calculated in the state \(Ramp\). A return to normal condition is reached when the event \([ECPNonHz-HzStop<Fgrid]\) is raised. \(ECPNonHz\) is the nominal frequency, and \(DeltaHzStr\) and \(HzStop\) represent deviations from \(ECPNonHz\). See Table 14. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline HLUC & Variable & Description & Type & Value & Format & Unit \\ \hline FW & Prt & priority of the use case & ParamUC & 2 & Float & - \\ \hline SelfC & Prt & priority of the use case & ParamUC & 1 & Float & - \\ \hline \hline \end{tabular}
\end{table} 
Table 18: Configuration of priorities. \begin{table}
\begin{tabular}{c c c c c} \hline \hline HLUC & PUC & Description & Type & Variable & Description & Type \\ \hline \hline  & & & SelfC\_BESS\_P & signal sent by the & Feedback \\  & & & HLUC SelfC to control & & \\  & & & the active power of & & \\  & & & the battery & & \\  & & & and SelfC & & FW\_BESS\_P & signal sent by the HLUC & Feedback \\  & & & FW to control the active & & \\  & & & power of the battery & & \\ \hline \hline \end{tabular}
\end{table} 
Table 17: PUC(Handling) to resolve \(C_{I}\) and \(C_{V}\). The information regarding conflict resolution exposed in Table 17 is transformed into a block diagram as shown in Figure 13a. However, not all the connections and inputs are generated. Some of them are manually included by the control engineer--for instance, the input fd_FW_Ena within the SelfC-block. The need for that input was realized during the running of simulations. Besides block generation, the function code embedded within the handling-block is also generated as shown in Figure 13b. The function \(CI\) retrieves the two control signals sent by PUC[SelfC] (Control[Self_BESS_P]) and PUC[FW] (Control[FW_BESS_P]). The priorities defined within the PUCs are also retrieved by the inputs \(Self\_prt\) and \(FW\_prt\).