3. Requirements Analysis 33
3.2. Non-Functional Requirements
[G. Mckoy]
The requirements outlined in this section serve as the non-functional requirements of this thesis. A tabularised short description is given in subsection 3.2.1 and more detailed descrip-tions in subsection 3.2.2. The detailed description encompasses the reasons and constrains behind these requirements.
3.2.1. List of Non-Functional Requirements
[G. Mckoy]
The table 3.2 gives a list of the requirements:
3. Requirements Analysis 39
No. Requirement Description Priority
MoSCoW 1 Java 7 and above Keep inline with the rest of the implementation by the
other partners.
M 2 Simulation
De-vices
The test environment should make use of simulation devices that will behave similar to the real system.
S 3 Testing of the
Java Python
Bridge version 2 and 3
The Java Python Bridge is the primary access point of the DER-System to the OS4ES project. All communi-cation must adapt to using the bridge with the excep-tion of the initial registraexcep-tion of a DER device and its services.
M
4 Setting up a test environment
A test environment is needed to assess the current status of the project and determine the necessary modifications to be done.
M
5 MQTT Compati-bility
The implementation must be able to communicate over MQTT.
M
6 Record data
to the influx database
Store the flexibility and forecast. S
7 Smart Gateway The Smart Gateway should act as the processing unit for the DER-System monitoring the use of resources attached, distributing the schedule and setpoints re-ceived among other functionalities.
S
8 Transparency The simulated devices should not be distinguishable from the real system to the rest of the OS4ES system.
S 9 Scalability The project is expected to support multiple
DER-Systems on a large scale. However this implemen-tation primary objective the feasibility of an end to end communication.
S
10 Security Security measures should be taken to sucre the sys-tem as much as possible regardless of it operating within a secure network.
S
11 Robustness The system should be developed and tested against multiple test case. The test cases should cover but not be limited to: Handling more than one device, dis-connecting a device and passing incorrect data to the device.
S
Table 3.2.: List of non-functional requirements
3. Requirements Analysis 40
3.2.2. Detailed Description the Non-Functional Requirements
[G. Mckoy]
Figure 3.2 describes the desired setup of the HUAS lab test. The figure focuses on the DER-System to be implemented whilst highlighting how the DER-DER-System will communicate with rest of the project namely the registry and aggregator.
Smart Gateway [G. Mckoy]
Figure 3.2.: DER-System and its communication over the middleware
A Smart Gateway should be developed that works as the main processing unit of the DER-System. The Smart Gateway should be capable of computing the flexibility of each DER device attached to it and offer this flexibility as an individual setpoint or as a schedule (ideally in the form of every 15 minutes for the next 24 hour).The Smart Gateway shall make use of the provided communication interface, the Java Python Bridge to interact with the rest of the system.
Below are the hardware and software specification for this requirement:
1. Hardware Requirements:
• The Smart Gateways shall be installed on a desktop computer capable of running the thrift server and handling multiple DER devices simultaneously
3. Requirements Analysis 41
2. Software Requirements:
• Operating system should be Linux based (debian based preferable).
• The provided middleware must be used to communicate with the rest of the sys-tem.
• The code must be developed in Java 7 or above.
MQTT Compatibility [G. Mckoy]
The real DER-units are connected to a server that is based on MQTT protocol. To commu-nicate with these DER-units in the network, a MQTT client is needed. The application being used to manage this service is Cybus. The implementation must be able to communicate with the MQTT broker running via Cybus.
Simulation of DER Devices [G. Mckoy]
The simulation models of a CHP, PV and a Battery should be implemented on two Rasp-berry Pis. The CHP should be on one of these devices and the Battery and PV on the second. These devices should then be connected to the Smart Gateway over the modbus communication interface to complete the DER-System.
The goal of a simulated devices is to be able to remove the Pis and attach a real DER-System without the rest of the OS4ES-system being able to distinguish the difference between the two. To accomplish this the simulated devices must behave the same as the real devices with respect to the way they receive and returns data. The simulation models can be a simple Python script that uses Modbus interface to communicate. Later the Matlab provided simulation models are to be converted into Python and integrated with the communication script created previously.
3. Requirements Analysis 42
3.2.3. Lab Test
[G. Mckoy]
A pre-lab test must be done to verify the functionality of the the physical devices before connecting them to the implementation of the end-to-end communication. This test should include but not limited to;
• Powering on and off the DER-units:
– This control must be done over the mqtt protocol.
– A secure sub-network must be used that will interact with the cybus network.
• Setting a setpoint or schedule:
– The systems do not have a storage device to receive a schedule and as such and intermediate application must be used to perform a storage behaviour which will distribute the schedule .
– Observation of the reaction time to each setpoint should be recorded to aid in the implementation.