## 5 Case Studies
### Case 2: A Setup Using Standards  
In the second use case, we created a setup based on LoRaWAN for transmission using an OPC UA server as a local IoT cloud for the cyber component of the sensor. The goal is a three-phase power  
Figure 3: Screenshot of the resulting dashboard.  
measurement and transmission to the EMS in at least 15-minute intervals. The setup consists of three folding current transformers (CT) with each 63A at 50 Hz, shown in Figure 4a, which are connected to the prototypes of a CT bridge (Figure 4b) The measurements of a CT are performed continuously and are recorded in the bridge as counter values. The bridge makes these values available via the LoRaWAN. The power supply of the bridge is done by energy harvesting from the CT. Therefore, it will be operated as LoRa class C device, although the sensor operation does not necessitate this receive mode.  
The CT bridge can connect up to 6 CT with maximum 250 A each. The configuration is done by transferring a static XML file via USB. The following parameters are specified: the transformer ratio of each CT and the type of measurement as true root mean square (RMS) or 50 Hz component. As we were interested in the power consumption and not in the real current, we chose the 50 Hz component. The consumption P equals:  
\[P=U\times J_{50 Hz}\times\cos(\varphi) \tag{2}\]  
The factory voltage U is known in most cases or must be measured separately; the power factor \(\cos(\varphi)\) is indicated on the label of the machine. The other parameters of the configuration apply to the LoRaWAN transmission: a send interval in seconds, the network key, the application session key, the spread factor (SF), and the receive port in the base station. Owing to the short distance to the base station and the limited power supply by energy harvesting, we chose SF = 10 and an interval of 900.  
The LoRa data frame has 26 bytes and contains the values of the six currents in ampere-seconds, as well as two values for temperature in degrees Celsius and humidity in percent (Figure 5). The semantics of this data is described via the JavaScript object notation (JSON) [78]. Figure 6 shows an abbreviated copy of this description.  
Figure 4: The setup with the CT (**a**), the CT bridge (**b**), and the base server (**c**).  
Figure 5: Our LoRa data frame.  
The radio counterpart provides a LoRaWAN base server, which is installed in an \(\Pi\) switch cabinet in the same production hall about 30 m away (Figure 4c). This is a commercially available device with a built-in LoRaWAN concentrator and network server, which operates in the ISM frequency band 863-870 MHz. The hardware platform with a TI AM33x chip is based on a Yocto embedded linux system. The LoRa application server, network server, and the gateway are implemented in C++ and the JavaScript based environment NodeJS. The base server supports two operating modes for packet forwarding: either as a pure LoRaWAN concentrator for use with an external commercial network server (a LoRa NaaS) or with internal packet relay to a built-in network server and a built-in OPC UA application server. We use the latter one. In this mode, the received data is interpreted and written into the address space of the OPC UA server. The JSON description of the payload is also entered and the values are connected to the OPC UA address space. The measured counter readings are now available on the OPC UA server.  
Figure 6: LoRa payload description in JavaScript Object Notation (JSON).  
The numerous steps for installation and configuration of the CT bridge, the LoRa base server, and the EMS result mainly from the prototypical character of the devices. The CT bridge is still a hardware prototype, in which configuration and software updates are carried out via manually imported files without any user interface.