MétaCan
Menu
Back to cohort
Record W2963261445 · doi:10.3390/electronics8080822

Low-Cost, Open Source IoT-Based SCADA System Design Using Thinger.IO and ESP32 Thing

2019· article· en· W2963261445 on OpenAlex

Why this work is in the frame

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

affAt least one author lists a Canadian institution in the pinned OpenAlex snapshot.
fundA Canadian funder is recorded on the work.

Bibliographic record

VenueElectronics · 2019
Typearticle
Languageen
FieldEngineering
TopicSmart Grid Security and Resilience
Canadian institutionsMemorial University of Newfoundland
FundersNatural Sciences and Engineering Research Council of Canada
KeywordsSCADAEmbedded systemModbusSupervisory controlArduinoController (irrigation)Instrumentation (computer programming)Computer scienceEngineeringComputer hardwareCommunications protocolOperating systemElectrical engineeringControl (management)

Abstract

fetched live from OpenAlex

Supervisory Control and Data Acquisition (SCADA) is a technology for monitoring and controlling distributed processes. SCADA provides real-time data exchange between a control/monitoring centre and field devices connected to the distributed processes. A SCADA system performs these functions using its four basic elements: Field Instrumentation Devices (FIDs) such as sensors and actuators which are connected to the distributed process plants being managed, Remote Terminal Units (RTUs) such as single board computers for receiving, processing and sending the remote data from the field instrumentation devices, Master Terminal Units (MTUs) for handling data processing and human machine interactions, and lastly SCADA Communication Channels for connecting the RTUs to the MTUs, and for parsing the acquired data. Generally, there are two classes of SCADA hardware and software; Proprietary (Commercial) and Open Source. In this paper, we present the design and implementation of a low-cost, Open Source SCADA system by using Thinger.IO local server IoT platform as the MTU and ESP32 Thing micro-controller as the RTU. SCADA architectures have evolved over the years from monolithic (stand-alone) through distributed and networked architectures to the latest Internet of Things (IoT) architecture. The SCADA system proposed in this work is based on the Internet of Things SCADA architecture which incorporates web services with the conventional (traditional) SCADA for a more robust supervisory control and monitoring. It comprises of analog Current and Voltage Sensors, the low-power ESP32 Thing micro-controller, a Raspberry Pi micro-controller, and a local Wi-Fi Router. In its implementation, the current and voltage sensors acquire the desired data from the process plant, the ESP32 micro-controller receives, processes and sends the acquired sensor data via a Wi-Fi network to the Thinger.IO local server IoT platform for data storage, real-time monitoring and remote control. The Thinger.IO server is locally hosted by the Raspberry Pi micro-controller, while the Wi-Fi network which forms the SCADA communication channel is created using the Wi-Fi Router. In order to test the proposed SCADA system solution, the designed hardware was set up to remotely monitor the Photovoltaic (PV) voltage, current, and power, as well as the storage battery voltage of a 260 W, 12 V Solar PV System. Some of the created Human Machine Interfaces (HMIs) on Thinger.IO Server where an operator can remotely monitor the data in the cloud, as well as initiate supervisory control activities if the acquired data are not in the expected range, using both a computer connected to the network, and Thinger.IO Mobile Apps are presented in the paper.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.

Full frame distilled prediction

Teacher imitation

Not calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

metaresearch head score (Codex)0.001
metaresearch head score (Gemma)0.000
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesnone
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Simulation or modeling · Consensus signal: Simulation or modeling
GenreCandidate signal: Empirical · Consensus signal: Empirical
Teacher disagreement score0.081
Threshold uncertainty score0.794

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0010.000
Meta-epidemiology (narrow)0.0000.000
Meta-epidemiology (broad)0.0000.000
Bibliometrics0.0000.000
Science and technology studies0.0000.000
Scholarly communication0.0000.000
Open science0.0000.000
Research integrity0.0000.000
Insufficient payload (model declined to judge)0.0000.000

Machine scores (provisional)

The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.

Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.

Opus teacher head0.012
GPT teacher head0.219
Teacher spread0.207 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it