One team from the PLC tag to the board report
Most plants are not short of data. They are short of the one hop that turns a controller tag into a number a manager can act on — collected automatically, stored where it can be queried, and delivered in the format the person receiving it already uses.
Softwell Automation builds that hop. We read from the PLCs, SCADA systems, energy meters and analysers a plant already owns, land the values in a SQL Server database inside the plant, and generate the shift, batch, energy and compliance reports the site actually runs on — as Excel, PDF, scheduled email and dashboards.
The sectors below are where we do this most often. Every one of them started as the same conversation: the data exists somewhere, nobody can get it out on time, and a manual register is filling the gap.
Delivery architecture
The same structure works from a single furnace to a plant-wide energy system. Convert once inside the plant, store in one database, and build every report from that database rather than from a second copy of the data.
The rule we hold to: no cloud service and no reporting tool polls a controller directly. A PLC scan cycle is not a web API, and most CPUs cap concurrent connections in single digits — which is why an existing SCADA screen goes grey when one more client is pointed at it.
Project expertise by sector
Scope, data sources, stack and the actual reports delivered in each type of project.
Steel plant — melting shop and rolling mill production reporting
- Typical data sources
- Furnace and mill PLCs, weighbridge, energy meters, crane and charge data, quality lab entries
- Communication
- Modbus TCP and RTU for meters, S7comm or OPC UA for Siemens CPUs, EtherNet/IP for Rockwell lines
- Data layer
- SQL Server tables for heats, charges, shifts, delays and energy, written by a Python or VBScript collector
- Reporting
- Heat-wise and shift-wise production, yield, specific energy consumption, delay analysis
A melting shop or rolling mill already generates every number management wants — it just lives in three PLCs, a weighbridge printout and an operator's register. The integration work is to collect those values against a common heat or coil identity and a common timestamp, so tonnage, energy and delay minutes can finally be compared in the same row.
We keep the existing control system untouched. The PLC program is read, not rewritten, and where a tag does not exist we agree the smallest possible addition with the OEM or the in-house team before anything is downloaded.
Reports and screens delivered
- Heat-wise report: charge weight, tap weight, yield, power-on time, kWh consumed, kWh per tonne
- Shift and daily production summary with cumulative month-to-date figures
- Delay and downtime report with reason codes captured from the HMI
- Section-wise or coil-wise rolling report with rejection and rework quantities
- Management PDF emailed at shift end and a plant display screen for the shop floor
Sealed quench furnace — heat treatment batch and recipe traceability
- Typical data sources
- SQF and tempering furnace controllers, thermocouples, carbon potential probes, quench oil temperature, charge and unload events
- Communication
- Modbus TCP/RTU from temperature controllers and recorders, OPC UA or S7comm from the line PLC
- Data layer
- Batch header and time-series tables — one batch identity linking recipe, setpoints, actual curve and operator
- Reporting
- Batch certificate with temperature and carbon potential curve, deviation log, furnace utilisation
Heat treatment customers are audited on evidence, not intentions. What an automotive or bearing customer asks for is a batch record that shows the actual temperature and carbon potential curve against the recipe, with deviations and who acknowledged them — and they ask for it years after the batch ran.
The integration captures the whole cycle automatically: soak temperature, carbon potential, quench oil temperature and time, and every alarm during the cycle, stamped against the batch and part number entered at charging. The same data set then answers the internal question nobody has time to calculate manually — units per cycle, cycle time and energy per batch.
Reports and screens delivered
- Batch traceability certificate as PDF: recipe versus actual curve, quench parameters, operator, part and lot number
- Deviation and alarm log per batch with acknowledgement record
- Furnace utilisation and cycle-time report by shift, day and month
- Energy per batch and per tonne of charge for the furnace and its utilities
- Searchable batch archive so a record from any past date can be reprinted on demand
Energy management system — plant-wide kWh, demand and energy per tonne
- Typical data sources
- Multi-function energy meters on feeders, transformers, DG sets, compressors and major drives
- Communication
- Modbus RTU over RS485 loops to a gateway or PLC, Modbus TCP where meters are on Ethernet, IEC 61850 on the HT side
- Data layer
- Interval energy tables at one, five or fifteen minutes with tariff periods, plus production tonnage for normalisation
- Reporting
- Feeder-wise consumption, maximum demand, power factor, energy cost allocation, specific energy consumption
Most plants have meters and no answers. The meters are installed, and the readings are copied into a spreadsheet once a day, which is enough to see the bill but not enough to change it. Reading every meter on an interval and storing it against production gives the number that actually drives decisions: energy per tonne, per batch or per machine hour.
Two practical things decide whether an EMS works: correct scaling and word order for every meter make on the loop, and clean time synchronisation so an interval on the meter matches the interval on the utility bill. Both are part of the commissioning checklist, and both are documented meter by meter in the handover file.
Reports and screens delivered
- Feeder-wise and section-wise consumption for shift, day, month and financial year
- Maximum demand trend with alerts before the contracted demand is crossed
- Power factor and penalty exposure by feeder
- Specific energy consumption: kWh per tonne, per batch or per unit produced
- Energy cost allocation by department for internal accounting, exported to Excel
- Live dashboard for the energy team and a monthly PDF for management review
Waste water treatment — ETP and STP compliance reporting
- Typical data sources
- Flow meters, pH, TSS, COD and BOD analysers, DO meters, blower and dosing pump status, level transmitters
- Communication
- Modbus RTU and TCP from analysers and flow meters, PLC tags for pump and blower run status
- Data layer
- Continuous interval logging with quality flags, alarm events and maintenance windows recorded separately
- Reporting
- Daily and monthly compliance reports, exceedance log, chemical consumption, pump and blower running hours
An effluent or sewage treatment plant is judged on records. The requirement is continuous logging of flow and parameters, a report that shows daily averages against consent limits, and a defensible explanation for every exceedance — including whether an analyser was in calibration at that moment.
We build the log so that the awkward questions are answerable: a quality flag on every value, a separate record for calibration and maintenance periods so those minutes are not silently averaged into a compliance figure, and an exceedance log with the operator action recorded against it.
Reports and screens delivered
- Daily compliance report: treated and discharged flow, pH, TSS, COD, BOD averages against consent limits
- Exceedance log with duration, peak value and recorded operator action
- Monthly summary in the format the pollution control board expects, as PDF
- Chemical dosing consumption and cost per cubic metre treated
- Pump, blower and aerator running hours for maintenance planning
- Analyser calibration and maintenance window record kept separate from compliance averages
Utilities and boiler — steam, compressed air and water monitoring
- Typical data sources
- Steam flow meters, boiler PLC, compressor controllers, water and air flow meters, pressure transmitters
- Communication
- Modbus TCP/RTU, OPC UA from the boiler or compressor PLC, pulse inputs for older meters
- Data layer
- Utility consumption tables aligned to the same shift calendar as production
- Reporting
- Steam and air consumption by section, generation cost, idle and leak load, boiler efficiency inputs
Utilities are usually the second biggest controllable cost after power, and the least measured. Logging steam, compressed air and water by section turns an argument about who is using what into a report, and the non-production-hour trace makes leak load visible without any additional instrumentation.
This work usually rides along with an energy project, because the meters land in the same database and the same shift calendar, and the marginal cost of adding them is small compared with commissioning a separate system later.
Reports and screens delivered
- Section-wise steam, compressed air and water consumption per shift and per day
- Idle-period and weekend baseline trace for leak identification
- Cost per tonne of steam and per unit of compressed air, with fuel input
- Compressor loading and unloading hours with specific power
- Utility consumption per tonne of product alongside the electrical figure
Machine shop and packaging — downtime, OEE and production dashboards
- Typical data sources
- Machine PLCs, counters, cycle signals, HMI reason-code entry, barcode or part scanners
- Communication
- OPC UA, EtherNet/IP, S7comm, Modbus TCP or direct digital signals where a machine has no network port
- Data layer
- Event-based tables: run, stop, reason, operator, product and quantity per cycle
- Reporting
- Availability, performance, quality and OEE by machine, shift and product
OEE only means something when the stop reasons come from the floor rather than from a guess at month end. The practical approach is a short reason-code list on the HMI, captured automatically against the stop duration, so a supervisor selects from six or eight options instead of writing a note in a register.
The output that changes behaviour is not the monthly OEE number, it is the live line display: current shift target versus actual, running downtime for the current stop, and the top three loss reasons of the shift on a screen the whole line can see.
Reports and screens delivered
- OEE by machine, line, shift and product with availability, performance and quality split
- Pareto of downtime reasons and duration for daily review meetings
- Live shift-target versus actual display for the shop floor
- Operator-wise and product-wise production summary
- Daily production email to supervisors and a monthly management pack
Reporting catalogue
Reports are built to the customer’s format, not to a product template. These are the ones asked for most often.
| Report | Built from | Frequency | Format | Usual recipient |
|---|---|---|---|---|
| Shift and daily production | PLC counters, weighbridge, batch records | Every shift, daily | Excel, PDF, email | Production head, supervisors |
| Heat-wise or batch-wise traceability | Furnace controllers, recipe and actual curves | Per batch, on demand | PDF certificate, archive | Quality, customer audit |
| Energy consumption and kWh per tonne | Energy meters plus production tonnage | Interval, shift, monthly | Dashboard, Excel, PDF | Energy team, management |
| Maximum demand and power factor | Feeder meters, HT incomer | Continuous with alerts | Dashboard, SMS or email alert | Electrical maintenance |
| Effluent and STP compliance | Flow meters, pH, TSS, COD, BOD analysers | Daily, monthly | PDF in board format | EHS, pollution control board |
| Downtime, reason codes and OEE | Machine PLCs, HMI reason entry | Live, shift, monthly | Dashboard, Pareto, Excel | Plant head, maintenance |
| Utility consumption — steam, air, water | Utility flow meters, boiler and compressor PLC | Shift, daily | Excel, dashboard | Utilities, finance |
| Alarm and event history | SCADA alarm logging, PLC alarm words | Continuous | Searchable table, Excel export | Maintenance, audit |
| Machine and asset running hours | Run status from PLC or meters | Daily, monthly | Excel, maintenance system feed | Maintenance planning |
| Management KPI pack | All of the above, consolidated | Monthly | PDF, Power BI | Plant head, directors |
Technology stack
We are not tied to a product line. The stack is chosen to fit what is already installed and what the IT team will support.
| Layer | What we work with |
|---|---|
| Controllers | Siemens S7-300/400/1200/1500, Rockwell ControlLogix and CompactLogix, Mitsubishi iQ-R, Q and FX5U, Schneider M241/M251/M262/M580, ABB AC500, Delta and OEM panels |
| SCADA and HMI | WinCC Explorer and WinCC in TIA Portal, FactoryTalk View, GX Works and GT Designer panels, EcoStruxure, and existing OEM HMIs left in place |
| Field and instruments | Multi-function energy meters, flow meters, pH, TSS, COD and BOD analysers, temperature controllers and recorders, weighbridge indicators, VFDs |
| Protocols | Modbus RTU and TCP, OPC UA, MQTT and Sparkplug B, S7comm, EtherNet/IP and CIP, SLMP, FINS, PROFINET, IEC 61850, REST and JSON |
| Database | Microsoft SQL Server — structured tables for time series, batches, shifts, alarms and downtime, with retention, indexing and backup agreed in writing |
| Application layer | Python with pyodbc, pandas and openpyxl; WinCC VBScript and ADODB where Python is not permitted on the station; SQL stored procedures |
| Output | Excel workbooks, PDF reports, scheduled email, web and Power BI dashboards, shop-floor display screens |
| Deployment | On-premise by default; edge gateway with local buffering where a site or cloud link is involved |
How a project runs
Six stages from first site visit to handover, with the tag list and the report formats agreed in writing before any database is built.
Site survey and tag list
We walk the plant with the maintenance team, list every controller, meter and instrument, confirm what is actually networked, and agree the tag list and the shift calendar that every report will use. This is the document the whole project is measured against.
Communication design
Protocol and port per device, switch and VLAN requirement, mirror port for verification, and the decision on where conversion happens. Where a port or register map is uncertain, we confirm it by capture rather than by datasheet.
Data collection layer
Gateway, OPC UA server or collector script commissioned, with scaling, word order and quality flags validated device by device against the panel meter or the HMI reading.
Database and historian
SQL Server schema built for the reports that were signed off — time series, batch headers, shift and downtime tables — with indexing, retention policy, backup and least-privilege accounts in place from day one.
Reports and dashboards
Each report built against the agreed format, reviewed with the person who will actually receive it, then scheduled: generated, emailed and logged automatically at shift end or day end.
Commissioning, training and handover
Parallel running against the existing manual record until the numbers agree, then training for the plant team and a handover file with tag list, register maps, schema, scripts and recovery procedure. Support continues after handover.
Why customers hand this to us
- We work with what you already have. The existing PLC, SCADA and meters stay. Integration reads from them; it does not replace them, and no control logic is rewritten without the OEM or in-house team agreeing it first.
- Vendor-neutral. Siemens, Rockwell, Mitsubishi, Schneider, ABB and OEM panels on the same line are the normal case, not a problem case.
- The reports are the deliverable. A dashboard nobody opens is not a project. The scope is written around the specific report each person receives, and signed off before the database is built.
- Documented handover. Tag list, register maps, database schema, scripts and recovery steps are handed over in writing. Being a training company, documentation and training the plant team is how we work anyway.
- Data stays in the plant. On-premise SQL Server by default, with least-privilege accounts and a backup policy. Cloud only where the customer asks for it, through a gateway that buffers locally when the link drops.
- Local presence. Based in Chinchwad, Pune, working across Maharashtra and travelling for site work elsewhere.