# Logic Control & Telemetry > Logic Control & Telemetry designs, builds, and commissions PLC, SCADA, telemetry, and industrial data historian systems across South Africa and Africa. TDengine system integrator. Legal name: Logic Control & Telemetry (Pty) Ltd Founded: 2014 Location: Grootfontein CE, Pretoria East, Gauteng, South Africa Contact: info@logiccontrol.co.za · 083 416 8457 TDengine status: TDengine System Integrator (SI) Canonical facts: https://logiccontrol.co.za/brand-facts Full corpus: https://logiccontrol.co.za/llms-full.txt ## Primary pages - [Home](https://logiccontrol.co.za/): Company overview and services - [About](https://logiccontrol.co.za/about): Company background and leadership (Manie Maritz) - [Contact](https://logiccontrol.co.za/contact): Email, phone, WhatsApp and enquiry form - [Brand facts](https://logiccontrol.co.za/brand-facts): Canonical quotable facts for AI systems ## Services - [Automation](https://logiccontrol.co.za/services/automation): Logic Control & Telemetry delivers end-to-end industrial automation: PLC programming, SCADA/HMI development, panel design, installation, and commissioning. - [Telemetry & IIoT](https://logiccontrol.co.za/services/telemetry): LCT builds telemetry and IIoT systems that collect field and PLC data, move it securely to operations centres, and support remote control where required. - [Analytics & Dashboards](https://logiccontrol.co.za/services/analytics): LCT builds analytics and dashboard layers that contextualise industrial time-series data for operations, engineering, and management. - [Reporting](https://logiccontrol.co.za/services/reporting): LCT implements automated industrial reporting so teams stop copying numbers from SCADA screens into spreadsheets. - [Panel Building](https://logiccontrol.co.za/services/panel-building): LCT builds and installs PLC and control panels as part of complete automation projects, not as isolated hardware jobs. ## TDengine - [TDengine hub](https://logiccontrol.co.za/tdengine): African TDengine Historian overview - [Industrial AI](https://logiccontrol.co.za/tdengine/industrial-ai): Asset context, TDgpt in-database analysis and self-hosted LLM options - [Root cause analysis](https://logiccontrol.co.za/tdengine/root-cause-analysis): AI-assisted fault investigation workflow and prerequisites - [Asset context](https://logiccontrol.co.za/tdengine/asset-context): Asset model, equipment relationships and loading manuals/SOPs as an AI knowledge base - [Historian](https://logiccontrol.co.za/tdengine/historian): TSDB + IDMP platform explanation - [PI System alternative](https://logiccontrol.co.za/tdengine/pi-system-alternative): How TDengine Historian covers PI storage, assets, dashboards, Excel and events - [Migration](https://logiccontrol.co.za/tdengine/migration): PI to TDengine phased migration guidance ## Industries - [Water & Wastewater](https://logiccontrol.co.za/industries/water-wastewater): LCT helps municipalities and water utilities automate plants, monitor remote assets, and produce reliable compliance and operations reports. - [Mining](https://logiccontrol.co.za/industries/mining): LCT does the PLC/SCADA work at the plant, telemetry for remote infrastructure where the link drops, and tag history that keeps up with high ingest rates. - [Power & Utilities](https://logiccontrol.co.za/industries/power-utilities): LCT works on the alarm floods and SCADA islands utility operators live with, and on operational records that stand up to an audit. - [Manufacturing](https://logiccontrol.co.za/industries/manufacturing): LCT helps manufacturers automate machines and lines, then turn the resulting data into shift, downtime and quality numbers in dashboards and reports production will sign off. ## Content hubs - [Insights](https://logiccontrol.co.za/insights): Technical articles ## Optional markdown twins Append `.md` to content URLs for raw markdown (example: `/about.md`). --- # Extended corpus ## Service: Industrial automation and control systems Logic Control & Telemetry designs, programmes, and commissions PLC and SCADA systems for industrial plants across South Africa — from greenfield panels to brownfield upgrades. Capabilities: - PLC logic development and FAT/SAT support - SCADA/HMI graphics, alarms, and trending - Industrial networking and protocol bridging - Safety interlocks and sequence control - Remote support and lifecycle maintenance FAQ: Q: Which PLC platforms does LCT work with? A: Typical South African plant platforms include Siemens, Schneider Electric, and Rockwell/Allen-Bradley. Tell us your installed base; we programme and integrate rather than forcing a rip-and-replace. Q: Does LCT handle panel building as well as software? A: Yes. We can take projects from control philosophy through drawings, panel building, installation, PLC/SCADA software, and final commissioning. Q: Can LCT upgrade a live plant? A: Yes. Brownfield work is planned around change windows, parallel systems where needed, and clear rollback paths so production impact stays controlled. ## Service: Telemetry and industrial IoT remote monitoring Remote monitoring and control for distributed assets using OPC-UA, MQTT, cellular/radio links, and secure data gateways — built for utilities, mines, and industrial sites. Capabilities: - Field device and PLC data collection - Cellular, radio, and IP telemetry links - IIoT gateway configuration and hardening - Alarm forwarding and exception-based monitoring - Integration into SCADA and TDengine Historian FAQ: Q: What protocols does LCT support? A: OPC-UA and MQTT, plus Modbus and DNP3 where the installed base uses them — common on South African utilities and mines. Q: Can telemetry feed a modern historian? A: Yes. Telemetry data can land in the historian you already run, or in TDengine — for long-term storage, dashboards, and reporting. Q: Is remote control included? A: Where required and approved, we implement remote control with authentication, auditability, and fail-safe behaviour — not just one-way monitoring. ## Service: Industrial analytics and operational dashboards Turn plant and telemetry data into operator dashboards and KPI views — on SCADA, web dashboards, or TDengine IDMP when that is where your tags live. Capabilities: - SCADA trending and overview screens - TDengine IDMP panels and real-time analysis tasks - Role-based views for operators vs managers - Exception and event visualisation - Integration with reporting and compliance outputs FAQ: Q: Do dashboards require a cloud subscription? A: No. We design for on-prem, private cloud, or hybrid deployments depending on your security and connectivity constraints. Q: Can LCT reuse existing SCADA graphics? A: Often yes. We extend what works, replace what does not, and avoid rebuilding screens that operators already trust. Q: What makes a dashboard one that operators actually use? A: Answering a question the operator already has, on the screen they already watch. Dashboards fail when they show every available tag instead of the handful that indicate whether the plant is behaving. We start from the decisions the shift has to make, then work backwards to the data those decisions need. ## Service: Industrial reporting and compliance data systems Automated production, quality, and compliance reporting from plant and historian data — including water quality reporting aligned to SANS 241 requirements. Capabilities: - Shift, daily, and monthly production reports - Quality and exception summaries - SANS 241-oriented drinking water reporting workflows - Data validation and missing-data flags - Delivery by email, portal, or file share FAQ: Q: Can reports pull from both PLC/SCADA and laboratory data? A: Yes. We design reporting around the systems you already have, including historians, SCADA archives, and manual lab inputs where needed. Q: Does LCT support SANS 241 reporting? A: Yes. We build the month-end / compliance pack from plant and laboratory data, with gaps flagged, so the works stop copy-pasting from SCADA. LCT builds the reporting workflow from the tags and lab inputs; we do not replace the utility's compliance officer. Q: What happens when data is missing from a reporting period? A: The report says so. Gaps are flagged rather than silently averaged over, because a report that hides missing data is worse than one that admits it — especially where the output supports a compliance position. Validation rules and missing-data flags are part of the build, not an afterthought. ## Service: Control panel design, building and installation Design, assembly, wiring, and installation of industrial control panels — delivered with drawings, labelling, testing, and site commissioning support. Capabilities: - PLC and remote IO panels - Motor control and instrumentation panels - Telemetry and communications cabinets - Labelling, wiring schedules, and as-builts - Integration with PLC/SCADA software delivery FAQ: Q: Does LCT only supply panels, or full projects? A: Both. Many clients prefer one integrator for panels, PLC software, SCADA, and commissioning so accountability stays clear. Q: Can LCT match an existing plant standard? A: Yes. We follow your preferred hardware standards, naming conventions, and documentation formats where specified. Q: What documentation comes with a panel? A: Manufacturing drawings, wiring schedules, labelling and as-builts that reflect what was actually installed rather than what was originally drawn. Maintenance teams inherit the panel long after commissioning, so the documentation is part of the deliverable rather than a favour. ## Industry: Water and wastewater automation and data systems PLC/SCADA, telemetry, and historian solutions for water treatment, distribution, and wastewater plants — with SANS 241 reporting workflows for drinking water supply, and operational reporting across the rest of the network. Typical challenges: - Distributed pump stations and reservoirs that are hard to monitor - Ageing PLC and SCADA systems with sparse documentation - Manual reporting that delays compliance and operations decisions - Need for a plant historian: years of tags for investigations and reporting, not only the SCADA archive How LCT helps: - Plant automation and brownfield SCADA upgrades - Telemetry for remote sites over cellular and radio - Reporting workflows that align online process data with laboratory SANS 241 results - TDengine Historian for scalable tag storage and dashboards FAQ: Q: How do you produce the SANS 241 month-end pack without disrupting the works? A: The month-end / compliance pack is built from plant (online) and laboratory data while operations keep running. Lab vs online sits in one workflow, not a spreadsheet assembled from SCADA screens. LCT does not replace the utility's compliance officer. Q: Can LCT modernise a municipal water works without full rip-and-replace? A: Yes. We typically phase upgrades: stabilise control, improve telemetry, then add historian/reporting layers so operations keep running. ## Industry: Mining plant automation and industrial data Control system integration, telemetry, and time-series historian work for mining plants and remote infrastructure across Southern Africa. Typical challenges: - Remote pumps and plants where the cellular or radio link drops for hours - High-volume process data that overwhelms legacy archives - Integration between plant control and enterprise reporting How LCT helps: - PLC/SCADA projects for process areas and utilities - Telemetry and gateway architectures for remote assets - TDengine Historian for high-ingest industrial time-series FAQ: Q: Does LCT work on both plant and infrastructure systems? A: Yes — process areas, utilities, water circuits, and remote monitoring for supporting infrastructure. Q: How do you monitor remote sites where the link is unreliable? A: By assuming the link will drop. Gateways buffer locally and forward when the connection returns, so a lost cellular or radio window becomes a gap that fills itself rather than data you never see. Control stays in the PLC so the site keeps running regardless of the link. Q: What if our current historian cannot keep up with the data volume? A: That is a common reason mines start looking. When ingest rates or retention limits force you to thin out tags or shorten history, you lose the record you need for downtime and quality investigations. TDengine Historian is built for high-ingest industrial time-series, so the decision about what to keep becomes an engineering one rather than a licensing one. ## Industry: Power and utilities control and telemetry Automation, telemetry, and historian integration for power and utility environments where uptime, alarms, and auditability matter. Typical challenges: - Legacy telemetry and SCADA islands - Alarm floods without clear prioritisation - Years of high-resolution tags that the current archive cannot retain or query affordably How LCT helps: - SCADA and telemetry consolidation - Alarm and event workflow improvements - Modern historian options including TDengine FAQ: Q: Can LCT integrate with existing utility SCADA? A: Yes. We design around your installed base and add gateways, historians, or reporting layers without forcing an unnecessary platform change. Q: What can be done about alarm floods? A: Alarm floods are usually a configuration and prioritisation problem rather than a software one. The work is reviewing which alarms actually require an operator action, removing or reclassifying the rest, and grouping related events so one upstream fault does not present as fifty separate alarms. Historian data makes that review evidence-based instead of a matter of opinion. Q: How long can operational records be kept for audit purposes? A: As long as the retention policy requires, provided the historian's commercial model does not penalise it. Retention is set per data set, so high-resolution tags and long-term compliance records can be held on different schedules rather than forcing one compromise across everything. ## Industry: Manufacturing automation and factory data systems Factory automation, machine integration, dashboards, and industrial data historians for manufacturers who need reliable production visibility. Typical challenges: - Machines and lines that do not share data cleanly - Paper or spreadsheet production reporting - Limited historical context for quality and downtime analysis How LCT helps: - PLC/SCADA and machine integration - Production dashboards and downtime visibility - Historian-backed analytics with TDengine where appropriate FAQ: Q: Does LCT only do greenfield factory projects? A: No. Most work is brownfield: connecting existing machines, improving SCADA, and adding reporting without stopping production. Q: How do you get data out of machines that do not share it cleanly? A: Machine by machine, using whatever each one exposes — native PLC protocols, OPC-UA, Modbus, or a gateway where the machine offers nothing useful. The aim is a consistent set of tags with agreed names and units, because mixed naming is what makes cross-line comparison impossible later. Q: Can automated reporting replace our production spreadsheets? A: Usually, and the honest constraint is data quality rather than reporting tooling. Once the underlying tags are trustworthy, shift, downtime and quality reports can be generated on a schedule from historian data. We normally run the automated pack alongside the spreadsheet until the numbers agree, then retire the manual version. ## TDengine industrial AI TDengine Historian pairs time-series storage (TSDB) with an asset and knowledge layer (IDMP). AI features need that context built first — they are not automatic out of the box. Four layers must be in place before AI can answer plant questions: - Data (TDengine TSDB): Stores the signals. High-ingest time-series storage for plant and telemetry tags, with long retention and SQL access. Nothing here understands what a tag means — it stores values against timestamps. - Context (TDengine IDMP — asset model): Explains what the signals mean. An asset tree plus a relationship network. The tree tells an AI agent what a thing is and where it sits. The relationship network tells it what that thing feeds, controls and affects — which is what makes causal reasoning possible instead of correlation guessing. - Knowledge (TDengine IDMP — knowledge base): Supplies the plant-specific experience. Manuals, SOPs, P&IDs, calibration records and past failure reports attached directly to the asset they describe. IDMP parses and indexes them so AI Chat and investigations can search your manuals, SOPs and drawings by asset. Extracted terms are associated with the model where they match; mismatches are corrected during load, not assumed correct on upload. - Intelligence (TDgpt + your chosen LLM): Does the analysis and the reasoning. TDgpt is TDengine’s time-series AI engine. It is installed as a separate module alongside TSDB and invoked from SQL so forecasting, anomaly detection and imputation run against data that stays in the database. A separate large language model handles language, multi-step reasoning and report writing — including root cause analysis. TDgpt is TDengine’s time-series AI engine (installed as a module). It runs numerical analysis (forecasting, anomaly detection, imputation) via SQL and does not read documents. An external, swappable LLM over an OpenAI-compatible interface handles language, reasoning and report writing — including root cause analysis — and may be self-hosted. ### Root cause analysis workflow 1. Intent recognition — The system reads the event context and determines the analysis goal. 2. Element confirmation — The associated asset, device identity, occurrence time and symptom are taken from the event. 3. Data retrieval — SQL is generated to fetch time-series for that element around the event — typically the last ten days in TDengine’s documented workflow, not the whole archive. 4. Data exploration — Python analysis runs on the retrieved series to find outliers, trends and correlations. 5. Knowledge retrieval — When manuals, SOPs and failure history are loaded on the asset, TDengine’s AI features search that plant knowledge first. Public technical references and known failure modes for this equipment type are the fallback — and are what the built-in event RCA works from where no plant knowledge has been loaded. 6. Hypothesis decomposition — The problem is split into one or more candidate causes. 7. Hypothesis verification — Each candidate is tested against the actual measurements. Hypotheses the data contradicts are discarded. 8. Report generation — A structured Markdown report: overview, timeline, data findings, ranked causes with evidence, and recommended actions for the engineer to judge. ### Knowledge attached to assets - Equipment manuals: Vendor manuals and engineering handbooks. IDMP indexes them for AI Chat, so questions about expected operating range, service intervals and alarm setpoints come from the document rather than guessed. - Standard operating procedures: The procedure for that equipment, attached to the element or its template. It lives on the asset (and can sit on the operator panel) instead of a departmental shared drive. - P&IDs and drawings: Process and instrumentation diagrams attached at the right level of the hierarchy. They are indexed with the asset, so engineers and AI Chat use the same drawing. - Calibration and maintenance records: Calibration reports attach as related documents. Notes on the element can hold maintenance and incident history — often the first place to look when a measurement starts to drift. - Failure case history: Incident reports and post-mortems attach like any other document, so they are searchable with the asset. Turning them into a structured case library — symptom, cause, remedy — is extra work TDengine supports; it is not automatic on upload. - Site photographs: Site photos upload with Word, PDF, Markdown and process drawings. The system parses and indexes them with the rest of the knowledge base. ### Equipment relationship types - Process flow (feeds, upstream-of, measures): How material, energy and information move between equipment. Lets an investigation walk backwards up a process chain. - Control and redundancy (controls, controls-by, interlocks-with): Which asset commands which, and what is forced to trip with it. Distinguishes a control action from a process disturbance. - Fault impact (affects, affects-by, redundant-with): How a fault travels, and which asset stands in as backup. Encodes the paths an experienced engineer walks when a symptom appears downstream of its cause. ### How LCT builds asset context 1. Model the assets — Build the asset model from your real plant structure: hierarchy, templates for repeated equipment classes, engineering units, limits and categories. Templates matter — they are what make a 400-pump site tractable. 2. Encode the relationships — Work through process flow, control and fault propagation paths with your process and maintenance engineers. This is the step most often skipped, and the one that decides whether root cause analysis can reason or only correlate. 3. Load the knowledge — Collect the manuals, SOPs, drawings and incident reports that exist and attach them at the correct element or template level. A structured case library — symptom, cause, remedy — is optional follow-on work if you want precedent matching, not something that happens when you upload a PDF. 4. Wire the language model — Connect an OpenAI-compatible endpoint — hosted or on-premises — configuring both an everyday query model and a deep-reasoning model for investigations. Set permissions before the agent is exposed to anyone. 5. Write the skills — Capture your own troubleshooting procedures as versioned skills so a specific plant’s judgement sequence is reproducible across shifts, not dependent on who is on duty. 6. Validate against known events — Replay incidents your team already understands and check the conclusions. An investigation assistant earns trust by getting known answers right before anyone relies on it for unknown ones. ### Data sovereignty - No vendor lock to a model: TDengine does not bundle a language model. You choose a hosted provider, a privately deployed model, or one running entirely inside the plant. Any OpenAI-compatible endpoint works, including a local Ollama or vLLM service with no API key. - Knowledge stays yours: Your asset model, documents, rules and skills are your assets, held in your system. With a local model, plant knowledge never crosses your network boundary — which is what makes this viable for operators who cannot send process data to a public API. - The agent inherits permissions: Access control applies to AI features as well as people. Elements a user cannot access are hidden in the asset tree — including from the agent acting for them — so an assistant is not a way around authorisation. - Every change can be audited: IDMP’s audit trail (off until an administrator enables it) logs who changed which object, when, and from where, in a tamper-proof record. TDengine also describes tracing skill calls and AI operations; we confirm the exact log scope on the build you run. ### FAQ Q: Can AI find the root cause of a plant fault? A: It can produce a ranked, evidence-tested set of hypotheses and the report behind them, provided it has context. On its own a language model has never seen your plant and cannot do this. TDengine IDMP supplies the missing context through an asset model, typed relationships between equipment, and your own manuals, SOPs and failure history attached to the assets they describe. The engineer still makes the final judgement. Q: Can LCT load equipment manuals and SOPs into TDengine? A: Yes. TDengine IDMP allows documents — manuals, SOPs, P&ID drawings, calibration reports, incident reports and site photographs — to be attached directly to an asset or to an element template. IDMP parses and indexes them for search by asset. Equipment names and fault types found in a document are associated with matching objects in the asset model during load — we verify those links, they are not guaranteed correct without review. The AI then answers questions about that asset from your documents first. Q: What is the difference between TDgpt and the LLM? A: TDgpt is TDengine’s time-series AI engine. It is installed as a module and does the numerical work — forecasting, anomaly detection and imputation — invoked from SQL, with that analysis staying in the database. It does not read documents and it does not require an LLM. A separate large language model, connected over an OpenAI-compatible interface, handles natural-language questions, panel generation, multi-step reasoning and report writing. Root cause analysis uses the deep-thinking LLM, not TDgpt. Q: Does our process data have to leave site for AI to work? A: No, provided the language model is hosted on your side. TDgpt analysis never leaves the database — it runs inside TDengine and does not need an LLM at all. Chat, panel generation and root cause analysis do send retrieved time-series windows and document excerpts to whichever OpenAI-compatible endpoint is configured. A local service keeps that traffic on your own network; a hosted provider means those excerpts leave site under your agreement with that provider. Q: How much of this is TDengine and how much is LCT? A: The platform capability is TDengine’s. The work that makes it useful on a specific plant is ours: modelling the asset hierarchy, encoding process and fault-impact relationships, gathering and attaching the document set, configuring the model connection and permissions, writing skills for your procedures, and validating results against incidents your team already understands. Q: Can TDengine replace our asset model and operator screens? A: IDMP is TDengine’s asset and visualisation layer — hierarchy, templates, attributes and operator panels in the same product as the historian. On top of that you attach manuals, SOPs and P&IDs so an assistant can answer from your documents, with a language model that can run on-premises. That covers a first historian, a SCADA archive that was never built to hold long history, and replacing PI Asset Framework plus PI Vision. Where PI is involved, the asset model is rebuilt from your plant rather than imported from AF — a considered model of the equipment that matters, not a dump of every PI interface. Q: How long does an AI root cause investigation take? A: TDengine reports a structured investigation report typically within a few minutes of launching it from an event detail page. The documented workflow retrieves a recent window of data for the event’s asset (typically the last ten days), explores it statistically, looks up technical references, then tests hypotheses. Plant manuals and failure history improve the result when they are loaded on the asset; they are not assumed to be present. Q: What has to be in place before root cause analysis is useful? A: Four things: tags landing reliably in TDengine TSDB; an asset model — hierarchy plus the relationships between equipment, not just the tree; the relevant manuals, SOPs and failure history attached to those assets if you want plant-specific precedent; and a deep-thinking language model configured. Skip the model and documents and the analysis has only a recent window of tags and public technical references to work with. Q: Does root cause analysis need a different model to normal queries? A: Yes. IDMP uses two models from one connection — a fast, inexpensive model for everyday natural-language queries and panel generation, and a separate deep-reasoning model invoked for extended analysis such as root cause investigation. Both are configured in the AI connection. Q: Can we encode our own troubleshooting procedure? A: Yes. TDengine calls these skills: procedures written in plain language that the system versions and reuses, so an AI assistant follows them step by step. A shift leader’s diagnostic sequence becomes something any shift can invoke, rather than knowledge that leaves with the person. Q: Should we trust an AI root cause report? A: Treat it as a prepared investigation, not a verdict. It should be validated against incidents your team already understands before anyone relies on it, and the report is structured to show the evidence behind each hypothesis precisely so an engineer can check the reasoning rather than accept a conclusion. Q: What is the asset model in IDMP? A: The plant structure IDMP uses to give tags meaning. It has two parts: a hierarchy (site, area, line, equipment) and typed links between equipment — what feeds what, what controls what, how a fault spreads. Together they let people and AI search by asset instead of by table name. Q: Why do asset relationships matter more than the hierarchy? A: A hierarchy tells you a pump belongs to a pump station. It does not tell you that the pump’s discharge pressure depends on upstream reservoir level and downstream valve position. Those associations usually live in a process engineer’s head. Encoding them as typed relationships is what allows an investigation to trace back along a real process path instead of correlating unrelated tags. Q: What file types can be attached to an asset? A: Word documents, PDFs, Markdown, process drawings and site photographs are parsed and indexed on upload. You do not need a keyword taxonomy upfront. IDMP extracts equipment names, fault types and operating steps from the documents and suggests links to the corresponding assets; we verify during load that documents land on the right assets and templates. Q: Do documents attach to every asset individually? A: Not necessarily. Documents can attach to an element template as well as to an individual element, so a manual that applies to every pump of a given model is attached once to the template rather than repeated across hundreds of assets. Q: We have no document set worth loading. Is this still worth doing? A: The asset model and relationships deliver value on their own — navigable data, templated dashboards, contextual events and better natural-language querying. The knowledge base then improves as documents are added. In practice most plants have more material than they expect, scattered across shared drives and filing cabinets; the harder part is usually collecting it rather than creating it. ## TDengine Historian and the PI System comparison Q: Is Logic Control & Telemetry a TDengine partner? A: Yes. Logic Control & Telemetry is a TDengine System Integrator (SI). We evaluate, prove and deploy TDengine Historian on South African and African plants — from a first tag ingest through dashboards, asset models and, where you need it, running beside an existing historian. Q: What is TDengine Historian? A: TDengine Historian is an industrial data platform in two layers. TDengine TSDB stores high-frequency plant tags with long retention and ordinary SQL. TDengine IDMP sits on top: asset models, operator dashboards, events, notifications, and — if you load manuals and SOPs — a knowledge base the AI features can actually use. Q: What makes TDengine AI-native rather than just a database? A: Storage is only the first layer. TDgpt (installed as a module) runs forecasting, anomaly detection and imputation from SQL so that numerical work stays in the database. IDMP then gives those numbers meaning: an asset model, how equipment connects, and — if you load them — your own documents attached to the assets they describe. Chat and dashboards-from-language use a language model you choose on your network. Root cause analysis uses a separate deep-reasoning model on the same OpenAI-compatible connection. Q: Can LCT run a proof of concept on our tags? A: Yes. A typical PoC takes a bounded set of tags from PLC, SCADA or an existing historian, then shows ingest, queries, dashboards and the reports you already run. If industrial AI is in scope we also model a small asset group and load its documentation, so you can see the knowledge layer working, not just empty storage. Q: Is TDengine a full PI System replacement? A: The core historian jobs — tag storage, asset models, dashboards, Excel reporting, events, connectors and open APIs — live in one TDengine Historian platform instead of a core server plus paid add-ons, but every PI installation is different. AF models, Vision displays, DataLink workbooks, event frames and custom integrations have to be rebuilt and proven on your own tags before anyone calls it a full replacement. Q: Do we have to rip out PI in one cutover? A: No. TDengine is designed to run beside PI. New values stream in while PI stays live; history is backfilled in batches; applications move only when the numbers match. You keep a rollback path the whole way. Q: Why are African sites looking at TDengine? A: They still need a serious historian — long retention, asset context, dashboards their teams will use — without stacking extra licences for visualisation and Excel. TDengine’s published model prices by tag count and includes dashboards and Excel access in the historian, so many sites avoid separate PI Vision and DataLink seat costs. We confirm current licensing against your tag inventory in discovery, and every PI installation still needs a proof of concept on its AF and reports. SQL is built in, and industrial AI can run against data that stays on site. Q: How does TDengine IDMP compare to PI Asset Framework? A: IDMP covers the same job as Asset Framework plus PI Vision — equipment templates, attributes, hierarchies and operator displays — once we rebuild them from your plant. There is no AF import: we inventory the AF structure and rebuild the templates, attributes and panels your team actually uses. It then goes further. You attach manuals, SOPs and P&IDs to those assets and IDMP indexes them, so an AI assistant can retrieve them — but only after the documents are loaded and a language model you control is connected, which can run on your own network. AF models the plant well; IDMP is built so the plant can also be queried in language. ### PI System to TDengine migration steps 1. Assess the PI system — Inventory PI Data Archive points, AF structure, users, interfaces, and dependent applications. Identify what must migrate first versus what can wait. 2. Deploy TDengine TSDB and IDMP — Stand up TDengine Historian components in the target environment (on-prem or approved cloud) and confirm networking, auth, and backup baselines. 3. Configure the PI connector path — Use TDengine taosX with the PI connector (PI AF SDK on Windows). If taosX is not on a Windows host that can reach PI, deploy a Windows taosX-Agent. Data Archive-only sources map to single-column models; Data Archive plus AF Server can use single- or multi-column mapping. 4. Start real-time streaming — Create a PI real-time task so new values flow into TDengine while the existing PI System remains operational. 5. Backfill history in controlled batches — Run PI backfill tasks by time range and point groups, monitoring PI load. Validate counts and spot-check values before expanding scope. 6. Rebuild context, dashboards and cut over — Model assets in IDMP, recreate critical panels and notifications, then phase applications off PI once parity is proven. Q: How long does a PI to TDengine migration take? A: It depends on how many tags, how much history, and how many applications read from PI. You do not wait until the end to see value: real-time streaming into TDengine can be running early, so operations can already query and chart the new historian while backfill and cutover continue in batches. Q: Does PI stay running during the migration? A: Yes. PI stays live and remains the system of record until you choose otherwise. TDengine fills beside it. Applications move only after we have matched counts and spot-checked values, so there is always a way back. Q: What happens to PI Asset Framework models? A: We inventory the AF structure in assessment and rebuild it in TDengine IDMP — templates, attributes and the relationships your team actually uses. The taosX PI connector (PI AF SDK on Windows) maps PI Points or AF elements into TDengine tables; that is ingest into TSDB, not a one-click copy of AF into IDMP. Real-time and backfill tasks run while PI stays live, so you do not need a weekend cutover for the data path. ## Insight: What held up — PLC, SCADA and telemetry since 2014 Published: 2023-11-23 · Updated: 2026-08-31 URL: https://logiccontrol.co.za/insights/decade-of-industrial-iot Since 2014 we have commissioned PLC, SCADA and telemetry on South African plants. What still works is stable control, telemetry designed for link loss, and reporting operators trust — not a platform swap on day one. Since 2014 Logic Control & Telemetry has commissioned PLC and SCADA work on factories, water works and power-related sites across South Africa. The pattern is consistent: stabilise control first, then add telemetry where assets are spread out, then fix reporting when operators stop trusting the numbers. ## What held up Deterministic PLC logic, conservative alarm design, and SCADA screens operators actually use during a fault. MQTT and OPC-UA only help when buffering and store-and-forward are designed for link loss — the same lesson as on [pump-station telemetry](/insights/opc-ua-mqtt-telemetry). Month-end packs still get built in Excel when the tags and the laboratory results never land in one workflow; that is a [reporting](/services/reporting) problem before it is a historian problem. ## What we would not repeat - Telemetry before the PLC program and alarms are stable - Sizing a historian from a vendor tag tier instead of the tags that matter for investigations and reports - A “connected plant” slide where the IO list and the P&ID are still open If that sounds familiar, start with one site or one report pack — not a platform swap. ## Where the work still sits - [Industrial automation and control](/services/automation) — PLC, SCADA, panels - [Telemetry](/services/telemetry) — OPC-UA, MQTT, Modbus and DNP3 where the installed base uses them - [Automated reporting](/services/reporting) and [dashboards](/services/analytics) from the data you already have - A historian when SCADA retention, query speed or tag licensing is the bottleneck — [TDengine Historian](/tdengine/historian) on a first install, a replacement, or beside the historian you already run ## Insight: OPC-UA and MQTT in South African telemetry projects Published: 2026-06-18 · Updated: 2026-08-31 URL: https://logiccontrol.co.za/insights/opc-ua-mqtt-telemetry When to use OPC-UA, MQTT, or the protocol already on the PLC — and where a gateway with buffering belongs when the link drops. Telemetry projects fail when protocols are chosen for fashion instead of fit. OPC-UA and MQTT both have roles on South African plants — often together, and often next to Modbus or DNP3 that is already on the PLC. The link will drop. Design for that first. ## OPC-UA where structure matters OPC-UA fits when tags need a typed model — units, alarms, structured objects — and SCADA or a gateway will browse them instead of remapping Modbus registers on every change. Use certificate-based client/server on the plant network. Keep deterministic control in the PLC; OPC-UA is how the rest of the system reads the plant, not how the loop is closed. ## MQTT where the wide-area link is the constraint MQTT fits pub/sub over slow or intermittent links — pump stations, reservoirs and skids publishing to a broker, with QoS where delivery matters, TLS on the wire, and SCADA subscribing downstream. It is for monitoring and selected setpoints, not sub-second closed-loop control. Buffer on the gateway so a lost radio or SIM does not lose the last hours of tags. ## A pattern that works A practical pattern we often recommend: 1. Keep deterministic control in the PLC 2. Expose selected process data via OPC-UA, Modbus, DNP3 or the native PLC protocol already on site 3. Use a gateway to poll those locally, buffer on link loss, then publish MQTT only across the wide-area link 4. Land the data in SCADA for operations and alarms first; add historian storage when you need multi-site trending, long retention, or reporting the SCADA archive cannot carry Security, buffering and store-and-forward matter more than the logo on the protocol slide. Design for link loss, not for perfect coverage. This is the architecture behind our [telemetry](/services/telemetry) work, most often on [water and wastewater](/industries/water-wastewater) and [mining](/industries/mining) sites where the links are the hard part. ## Insight: What drives PI System TCO after the first licence Published: 2026-03-12 · Updated: 2026-08-31 URL: https://logiccontrol.co.za/insights/rethinking-pi-system-tco PI System and AVEVA Historian are different products with different licence shapes. When tag count, client seats or renewal terms outpace what the plant uses, re-run the numbers against your own tag list — including TDengine Historian beside or instead of PI. AVEVA PI System is mature and familiar on many large sites. Growth cost is usually tied to tag count, named-user clients and add-on modules — not to a single line item on the first quote. It is not Wonderware. AVEVA Historian — still called Wonderware Historian on many South African plants — is the SQL Server-based process historian that sits with InTouch HMI and System Platform. PI System is the former OSIsoft stack (PI Server / Data Archive, Asset Framework, optional PI Vision) that AVEVA acquired in 2021. AVEVA still sells both. Mixing the names leads to the wrong commercial comparison and the wrong migration plan. ## The cost shape that hurts The problem is rarely the first invoice. It is the shape of the curve after it. On PI, cost has historically grown with tag count, named-user clients and add-on modules (PI Vision, PI DataLink, PI Integrator and others). Many new AVEVA deals run on Flex credits — a subscription currency across PI, AVEVA Historian, InTouch and System Platform — but plants on perpetual licences and support renewals still need a quote against their own tag list and contract terms, not a published rate card. Either way, the number to compare is the one scoped against what operations actually trends, reports on and alarms on. We deliberately do not publish a comparison table. Licensing on both sides moves, and tag-tier figures repeated out of context are usually stale by the time anyone reads them. The number that matters is the one built against your own tag count, user count, connectors, redundancy requirement and support terms. ## What most plants actually need from a historian Most South African plants do not need every niche PI add-on on day one. They need: 1. Reliable ingest from PLC/SCADA and telemetry 2. Long retention without thinning tags to fit a licence tier 3. Dashboards and reports operations teams will actually use 4. A path that does not demand a weekend rip-and-replace — TDengine can sit beside PI while the numbers are proven ## How LCT approaches evaluations We run proof-of-concept work that compares your real tag shapes, retention needs and report outputs — not brochure feature checklists. If PI remains the right answer, we will say so. If TDengine Historian (TSDB + IDMP) can cover the storage, asset context, dashboards and reports you depend on, we will quote it against your tag list — with PI still live beside it if that is the safer path. The capability comparison is set out on [TDengine as a PI System alternative](/tdengine/pi-system-alternative), and the phased approach that keeps PI live while TDengine is populated alongside it is on [PI System to TDengine migration](/tdengine/migration). ## Insight: SANS 241 month-end reporting without the spreadsheet Published: 2026-05-08 · Updated: 2026-08-31 URL: https://logiccontrol.co.za/insights/sans-241-data-layer SANS 241 is the month-end compliance pack. When it is still assembled by hand, start with the critical quality tags and one automated report — add a historian only if the SCADA archive cannot hold or query what you need. Most works managers already know SANS 241 from the month-end compliance pack: laboratory results, sampling points, and the spreadsheet that still ties them to what the plant was doing online. What often lags is not the standard — it is getting plant and lab data into one report without copy-paste from SCADA. ## What the pack actually needs A useful water data stack typically covers: - Continuous process measurements from instruments and PLC/SCADA — turbidity, chlorine residual, flows, levels - Laboratory results in the same workflow as the online tags, not a second spreadsheet - Gaps flagged so a missing sample or a dead instrument shows up before month-end - Reporting that operators and the compliance team can open without rebuilding the numbers Long-term tag retention helps investigations. It is not the first thing to buy if the month-end pack is still assembled by hand. ## What the month-end pack needs from the plant The compliance pack is not only laboratory results. Turbidity, chlorine residual, flows and alarms from SCADA need to sit beside lab data — with gaps flagged — so problems show up before the spreadsheet is due, not after. LCT builds that workflow from your tags and lab inputs. We do not replace the utility's compliance officer. ## Practical next step If your water works already has SCADA but the month-end pack is still manual, start with a narrow pilot: the critical quality tags, lab inputs in the same workflow, and one automated daily or weekly report. Add historian storage only when SCADA retention or query speed becomes the limit. Expand after operators trust the numbers. This is the work we do on [water and wastewater](/industries/water-wastewater) sites; the reporting workflow is covered under [industrial reporting](/services/reporting). Consider a [TDengine Historian](/tdengine/historian) evaluation only when retention, query speed or tag growth is the actual bottleneck.