Internal Errigal Collaboration Wiki

User Tools

Site Tools

Trace:
Writing /app/www/public/data/meta/development/applications/epic226.meta failed
development:applications:epic226

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

development:applications:epic226 [2018/11/09 16:07] – created cokeeffedevelopment:applications:epic226 [2021/06/25 10:09] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +=====EPIC 2.26 Server and Client=====
 +The EPIC 2.26 project mainly consisted of the creation of a pair of applications known as the EPIC 2.26 Server and Client. These are also internally referred to as the SEP Server or SEP Gateway and SEP Router or SEP Client respectively.
 +
 +These are multifunctional applications designed for several different use cases for PG&E each based around monitoring and controlling various kinds of devices in the field. In each case the Server and Client act in a similar role: The Client software is designed to run on an "Internet of Things Router" connected to various types of hardware, acting as a bridge between the different devices and the central Server application.
 +
 +====The Server====
 +The 2.26 Server (project name: [[https://bitbucket.org/errigal/sepgateway|SepGateway]]) has a similar stack to other Errigal projects: Grails 3.3.1, MySQL database using React+Redux for part of the frontend. A central server controls and gathers data from many clients in the field.
 +
 +===The Client===
 +The 2.26 Client (project name: [[https://bitbucket.org/errigal/sepgateway|SepRouter]]) is a more lightweight project, but still coded in Groovy and using Spring Boot. There is no real UI other than some controllers exposed for debugging purposes. It is intended to be deployed to [[https://developer.ssni.com/iot-edge-router-25-product-brief | Silver Spring Internet of Things Edge Router]] and communicated back to the server over PG&E's AMI mesh network. The router itself is an ARM device (like a Raspberry Pi) and its operating system is based on Canonical's [[https://developer.ubuntu.com/core|"Snappy Ubuntu Core"]] which means the application build needs to be packaged as armhf-architecture snaps. This has caused pains in trying to set up automated build server - currently builds are run manually on a Raspberry Pi reserved for this purpose.
 +
 +The client router is intented to be hooked via ethernet, serial or USB connections to different types of hardware end devices and facilitate communication between them and the server, effectively acting as a translater for different devices that don't have a way of natively finding and communicating with the central server.
 +
 +
 +====Use Cases/Hardware====
 +(Use Case 1 was cancelled)
 +
 +===Use Case 2: DER Devices (Smart Inverters)===
 +In this use case the client and server implement the [[https://standards.ieee.org/standard/2030_5-2013.html|IEEE 2030.5 protocol]] (previously known as Smart Energy Profile 2.0, hence the "SEP" name used in the codebase) for smart energy devices. In this case the client acts to bring these older "Distributed Energy Resource" devices up to the new standard. In practice the only DER Devices supported for this project are specific smart inverter models manufactured by Fronius and SolarEdge. The communication between the client and inverters is using Modbus over TCP, using a library called JLibModbus.
 +
 +On the server side, power control programmes can be created and scheduled for clients to apply to the inverters as defined under the 2030.5 protocol.
 +
 +
 +===Use Case 3: Evironmental Sensor===
 +The client is able to connect to special earthquake sensor devices over SFTP and retrieve and read sensor log files directly from the sensor's file system
 +
 +===Use Case 4: Smart Thermostat===
 +
 +===Use Case 5: Remote Communication and Control of Overhead and Underground SCADA/FLISR devices.===
 +The client is able to act as a relay for DNP3 (Distributed Network Protocol) commands for SCADA (Supervisory Control And Data Acquisition) systems. It receives SCADA commands and passes them on to the connected device and similarlly passes back the response.
 +
 +===Use Case 6: RFID Reader===
 +This case is mostly concerned with tracking inventory. PG&E tags boxes with RFID tags which are read by RFID readers in warehouses and on trucks. These readers are attached to one of the 2.26 client routers which passes back the readings to the server. In this case the client is acting as a simple relay for Low Level Reader Protocol (LLRP) commands between the server and the RFID readers. The server uses the readings to track inventory movement and calculate current inventory levels for warehouses. It even has a map display with icons indicating what warehouses are running low on inventory.
 +
 +The server also has a UI for sending batches of control commands to RFID readers and to view and manually edit reader configurations.
 +
 +===Use Case 7: Data Acquisition and Control Telemetry===
  

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki