This study did not involve human participants, animals, or identifiable personal data. The analyses were performed using a publicly available dataset (UK Power Networks Open LV Network & Smart Meter dataset) together with synthetically generated data for validation; therefore, ethics committee approval and informed consent were not required. The research tools used in the protocol are listed in the Table of Materials.
1. Data acquisition
The Low-Voltage (LV) Acceptance Automation Platform was developed using electrical measurements acquired from smart meters, IoT sensors, and the Open LV Network & Smart Meter Dataset. Electrical parameters, including voltage, current, active power, reactive power, and energy consumption, were collected through Wi-Fi-, PLC-, and RS-485-based communication protocols. Real-time measurements were used for live system monitoring, whereas historical data supported model development and validation.
The proposed framework used the Open LV Network & Smart Meter Dataset provided by UK Power Networks42. The dataset comprises household smart meter consumption, feeder-level load profiles, and feeder voltage measurements. Time-series subsets containing load consumption and voltage data were selected for model training and evaluation. In addition, a simulated smart meter dataset was generated to represent operational conditions and fault scenarios required for workflow validation and machine learning model evaluation. The simulated dataset included timestamped measurements of voltage, current, active power, reactive power, energy consumption, total harmonic distortion (THD), and voltage imbalance. Fault samples were generated by simulating undervoltage, overvoltage, excessive harmonic distortion, and voltage imbalance based on established low-voltage operational thresholds. The dataset characteristics are summarized in Table 1.
| Attribute | Description |
| Dataset Name | Open LV Network & Smart Meter Dataset |
| Simulated Smart Meter Dataset | Geneated 1000 smaples for Fault simulation and workflow validation |
| Data Type | Time-series (historical smart meter data) |
| Data Granularity | Household-level and feeder-level measurements |
| Key Features | Voltage, current, active power, reactive power, energy consumption, timestamps |
| Data Frequency | High-resolution (e.g., half-hourly / minute-level depending on subset) |
| Coverage | Residential low-voltage distribution networks |
| Usage in Proposed Work | Model training, validation, load behavior analysis, and acceptance workflow evaluation |
Table 1: Dataset description. Summary of the Open LV Network & Smart Meter dataset used for model development and performance evaluation. The table presents the dataset components, measured electrical variables, sampling characteristics, and dataset partitioning for training, validation, and testing.
Because the Open LV Network & Smart Meter Dataset does not contain predefined fault labels, a rule-based labeling strategy was applied to both the real and simulated datasets. Samples satisfying normal operating limits were assigned a label of 0 (Normal), whereas samples exceeding operational thresholds (e.g., voltage deviations greater than ±10% of the nominal voltage, THD > 5%, or voltage unbalance > 2%) were assigned a label of 1 (Fault). These labels served as the ground truth during model training, validation, and testing. The proposed rule engine also allows threshold values to be configured in accordance with regional standards or utility-specific acceptance criteria.
The dataset was partitioned into training (70%), validation (15%), and testing (15%) subsets. Missing values were addressed using linear interpolation, mean imputation, and forward-fill techniques as described in the preprocessing stage. To ensure statistical robustness and reproducibility, all experiments were repeated five times using different random seeds.
2. Data preprocessing
Raw data from the Open LV Network & Smart Meter Dataset and IoT sensor measurements were preprocessed to improve data quality prior to feature extraction and model development. Missing values, noise, and inconsistencies caused by communication interruptions and sensor malfunctions were identified and corrected using interpolation, mean imputation, and forward-fill techniques. The detailed mathematical derivations are provided in Supplementary File 1 (Section S1).
The preprocessed time-series data were segmented into representative operational intervals (S₁–S₅ and Sk). Statistical and electrical features, including average load, peak load, minimum load, standard deviation, voltage deviation, and power consumption, were extracted from each segment. The extracted features are summarized in Table 2 and served as inputs for the subsequent feature engineering stage.
| Segment ID | Mean Load (kW) | Peak Load (kW) | Min Load (kW) | Std Deviation (kW) | Voltage Deviation (p.u.) | Power Consumption (kWh) | Time Interval |
| S₁ | 2.45 | 3.8 | 1.2 | 0.65 | 0.032 | 58.4 | 00:00–01:00 |
| S₂ | 2.9 | 4.1 | 1.5 | 0.72 | 0.028 | 64.2 | 01:00–02:00 |
| S₃ | 3.25 | 4.85 | 1.8 | 0.81 | 0.035 | 71.6 | 02:00–03:00 |
| S₄ | 3.8 | 5.2 | 2.1 | 0.9 | 0.041 | 78.9 | 03:00–04:00 |
| S₅ | 4.1 | 5.75 | 2.4 | 0.95 | 0.045 | 85.3 | 04:00–05:00 |
| Sk | 3.6 | 5.1 | 2 | 0.88 | 0.038 | 76.5 | tk |
Table 2: Representative feature representation extracted from time-series segments. Representative statistical, electrical, load behavior, voltage stability, and power quality features extracted from segmented LV time-series data during feature engineering. The values illustrate the engineered feature representation and are not experimental performance results. LF = Load Factor; PAR = Peak-to-Average Ratio; VSI = Voltage Stability Index; PF = Power Factor; THD = Total Harmonic Distortion.
3. Feature engineering
Feature engineering was performed to improve the representation of the preprocessed data for workflow orchestration and intelligent decision-making. Principal Component Analysis (PCA)^43 was applied to reduce data dimensionality by removing redundant and highly correlated variables while retaining the most informative feature components. The mathematical derivations are provided in Supplementary File 1 (Section S2).
Statistical descriptors, load behavior indicators, voltage stability indices, and power quality metrics were derived from the segmented time-series data. These engineered features included Load Factor (LF), Peak-to-Average Ratio (PAR), Voltage Stability Index (VSI), Voltage Unbalance Index, Power Factor (PF), and Total Harmonic Distortion (THD). The resulting feature set was used as the input to the workflow orchestration and intelligent decision-making modules.
The feature engineering workflow is summarized in Supplementary File 1 (Supplementary Algorithm 1). The procedure consisted of segmenting the preprocessed data, extracting statistical and electrical features, calculating load behavior, voltage stability, and power quality indicators, and applying PCA to generate the final feature vector used for model training and validation.
4. Visualized process canvas design
The Visualized Process Canvas was developed as a graph-based workflow orchestration framework for automating low-voltage (LV) acceptance procedures. The workflow was represented as a directed graph, G = (N, E), where N = {n1, n2, …, nm}denotes the workflow nodes corresponding to individual processing stages (e.g., data input, preprocessing, validation, and decision-making), and E = {eij}represents the directed edges defining the execution sequence between nodes. This graph-based representation enabled the creation of configurable workflows and their automated execution without manual coding.
Each workflow node performed a specific processing task by receiving input data, executing predefined operations, and forwarding the processed output to subsequent nodes. Acceptance criteria, including voltage and load thresholds, were implemented as configurable validation rules that could be updated without modifying the workflow structure. The workflow supported both sequential and parallel execution to improve computational efficiency. Machine learning models were integrated into designated workflow nodes to perform anomaly detection and automated acceptance validation (Figure 2).

Figure 2: Visualized process canvas architecture for LV acceptance automation. Overview of the visual workflow orchestration framework used for LV acceptance automation. The process canvas illustrates the graphical organization of workflow nodes for data processing, feature engineering, rule-based validation, intelligent decision-making, and output generation to support workflow design, execution, and monitoring. Please click here to view a larger version of this figure.
The mathematical formulation describing information flow through the workflow graph is provided in Supplementary File 1 (Section S3). Supplementary File 1 (Supplementary Algorithm 2) describes the workflow orchestration procedure, including workflow traversal, node execution, rule validation, decision generation, and output aggregation.
The Visualized Process Canvas was implemented using a microservice-oriented software architecture to support scalability and modular deployment. The graphical workflow interface was developed using React.js to provide drag-and-drop workflow configuration. Backend orchestration services were implemented using Flask/FastAPI, while Eclipse Mosquitto served as the MQTT message broker for communication between workflow modules. EdgeX Foundry provided edge device management and IoT integration. Machine learning services were implemented with Scikit-learn, TensorFlow, and PyTorch, and containerized with Docker and Kubernetes.
5. Workflow orchestration engine
The workflow orchestration engine coordinated execution of the configured acceptance workflow. A detailed description is provided in Supplementary File 1 (Section S4), and the execution sequence is summarized in Supplementary Figure 1.
The workflow execution process consisted of validating the workflow definition, initializing the execution environment, scheduling workflow nodes according to their dependencies, executing nodes sequentially or in parallel, applying rule-based validation, aggregating intermediate outputs, and generating the final acceptance or rejection decision based on rule-based and machine learning evaluation. Execution results were published through dashboards, reports, application programming interfaces (APIs), and data storage services. The overall workflow orchestration process is illustrated in Figure 3.

Figure 3: Comparison of classification performance metrics across different methods. Comparison of the classification performance of IoT-LV, RBM, Support Vector Machine (SVM), Random Forest (RF), Long Short-Term Memory (LSTM), and the proposed framework using the Open LV Network & Smart Meter dataset. Performance is evaluated using Accuracy, Precision, Recall, and F1-score. Results are presented as mean ± standard deviation (SD) from five independent experimental runs using a 70%/15%/15% training/validation/testing split. Error bars represent one standard deviation. Please click here to view a larger version of this figure.
6. Intelligent decision module
The Intelligent Decision Module was developed to automate low-voltage (LV) acceptance decisions using supervised machine learning models. Classification and regression algorithms were applied to the engineered feature vectors to support operational decision-making. Classification models identified normal and abnormal operating conditions, whereas regression models estimated future energy consumption and operational trends.
The input feature vector, X ∈ ℝd, comprised the statistical, voltage stability, load behavior, and power quality features extracted during the feature engineering stage. Standalone Support Vector Machine (SVM)44, Random Forest (RF)45, and Long Short-Term Memory (LSTM)46 models were implemented as baseline classifiers for comparative evaluation. The mathematical formulation of the learning models is provided in Supplementary File 1 (Section S5).
For classification, the output variable y ∈ {0,1} represented normal (0) and abnormal (1) operating conditions. When abnormal operating conditions or overload events were detected, the workflow generated a fault notification and flagged the acceptance process as invalid; otherwise, the process was classified as accepted.
The workflow orchestration engine integrated machine-learning predictions with rule-based validation, using a priority-based conflict-resolution strategy. Safety-critical operational rules and regulatory acceptance criteria were treated as hard constraints and therefore took precedence over machine-learning predictions when conflicts occurred. Final acceptance decisions were generated using the combined outputs of the rule-based validation and intelligent decision modules.
7. Cloud–edge integration and visualization dashboard
A cloud-edge computing architecture was implemented to support scalable data processing, storage, and visualization for the LV acceptance automation platform. Smart meters, SCADA systems, and IoT devices continuously collect electrical measurements, which are processed at the edge layer via filtering, normalization, feature extraction, and real-time inference to reduce communication overhead and enable low-latency decision-making. The mathematical derivations are provided in Supplementary File 1 (Section S6).
Processed data were transmitted to the cloud layer for long-term storage, advanced analytics, feature engineering, model training, and model management. Interactive dashboards provided real-time system monitoring, alerts, reporting, and operational decision support. The cloud-edge architecture is illustrated in Supplementary Figure 2, and the implementation details are summarized in Table 3.
| Layer | Component | Hardware / Software | Specification / Version | Purpose / Description |
| Edge Layer | Edge Device | Raspberry Pi 4 / NVIDIA Jetson Nano | Quad-core CPU, 4–8 GB RAM | Real-time data acquisition and local processing |
| IoT Gateway | Industrial IoT Gateway | MQTT / Modbus / OPC-UA support | Communication between sensors and edge/cloud |
| Sensors / Smart Meters | Digital Smart Meters | Voltage, Current, Power Measurement | Data collection from LV network |
| Edge Software | Python, EdgeX Foundry, MQTT Broker | Python 3.x | Data preprocessing, filtering, local inference |
| Communication Protocols | Wi-Fi / PLC / RS-485 | Standard protocols | Data transmission to cloud layer |
| Cloud Layer | Cloud Platform | AWS / Microsoft Azure / Google Cloud | Scalable cloud services | Data storage, analytics, and model training |
| Storage | AWS S3 / Azure Blob / InfluxDB | Time-series database | Storing historical and real-time data |
| Compute & ML | Python, TensorFlow, PyTorch, Scikit-learn | ML libraries (latest versions) | Model training, evaluation, deployment |
| Containerization | Docker, Kubernetes | Latest stable versions | Workflow orchestration and scalability |
| Data Processing | Apache Spark / Pandas | Distributed processing | Large-scale data analytics |
| Visualization Layer | Dashboard Tools | Grafana / Apache Superset / Plotly Dash | Web-based tools | Real-time monitoring and visualization |
| Web Framework | React.js / Angular / Flask / FastAPI | Modern web stack | UI development and API integration |
| Notification System | Email / SMS Gateway / Push Notifications | Twilio / Firebase | Alert generation and communication |
| API Services | REST APIs | JSON-based communication | Integration between modules |
Table 3: System implementation details. Summary of the hardware configuration, software environment, communication protocols, and cloud–edge computing components used for implementing the proposed LV acceptance automation platform.