An MQTT message is only a topic plus a payload. A useful historian record needs more: stable equipment identity, typed measurements, a trustworthy time, and a schema that stays meaningful as devices and sites grow.

The central design decision is not “How do I parse JSON?” It is “Which parts describe the measurement, and which parts describe the source that produced it?” Make that decision before configuring an ingestion tool. Otherwise a technically successful write can create tables that are difficult to query, compare, or maintain.

Separate identity from measurements

Industrial MQTT topics often carry stable context. A topic such as plant-a/line-3/press-17/telemetry identifies a site, production line, asset, and message class. The JSON body should normally carry values that change over time, such as pressure, temperature, quality, and an event timestamp.

Use the topic for identity only when its levels are governed and stable. If a device identifier can change position in a topic, or if a topic level mixes identity with a changing state, extract the durable identity from a payload field or an asset registry instead. The goal is a single, understandable source identity that remains consistent across records.

Here is an illustrative payload, not connector configuration:

{

"event_time": "2026-10-27T08:15:04.125Z",

"asset_id": "press-17",

"pressure_kpa": 742.6,

"temperature_c": 46.1,

"quality": "good"

}

For this message, press-17 is an identity candidate, the two numeric values are measurements, quality is contextual state, and event_time needs timestamp validation. The topic may reinforce the identity, but it should not contradict the payload without an explicit resolution rule.

Define the destination model before mapping fields

Write a field-to-destination contract that every engineer can inspect:

For TDengine, a supertable defines a shared structure; its subtables represent individual sources and carry the supertable’s tags. The model needs a primary timestamp and at least one measurement column. That fits many equipment-telemetry patterns: use a stable source identity for the subtable, keep changing values as ordinary columns, and reserve tags for descriptive values shared by every row from that source. Do not put a rapidly changing measurement such as pressure into a tag merely because it appears beside the asset identifier in JSON.

Choose the table grain deliberately. A table per physical asset is often understandable for regularly sampled telemetry. When a payload contains readings from multiple assets, preserve each source’s identity and map the measurements to the appropriate subtables. Separate supertables may be appropriate when device types or message classes require different measurement schemas. Whatever you choose, avoid allowing arbitrary incoming field names to create an uncontrolled schema. That creates inconsistent columns and makes fleet-level queries unreliable.

Parse JSON with explicit types, units, and null rules

JSON has fewer type constraints than a historian. A value that looks numeric can arrive as a number, a quoted string, null, or a different unit after a firmware change. Set an expected type and unit for every measurement before ingestion:

- Parse numeric measurements as the agreed numeric type; reject or quarantine non-numeric values instead of silently converting them.

- Keep the engineering unit in the schema contract or a controlled asset attribute. Do not assume a field named pressure is always kPa.

- Define whether null means unavailable, unchanged, intentionally omitted, or malformed. The answer determines whether to store a null, skip the field, or send the message for review.

- Extract nested JSON values with named paths and validate the resulting field, rather than treating an entire nested object as a measurement.

Arrays need special care. An array can represent a batch of timestamped readings, a set of channels, or an unordered list. Map each case differently. Split a true batch into records only when every element has a clear identity and timestamp; otherwise archive or transform it through a controlled process.

Make source time and ingestion time distinct

Use source event time for the historical position of a measurement when the source can provide a valid timestamp. Validate its timezone, epoch unit or text format, allowed clock skew, and behavior after a device reboot. This matters especially after buffering or replay: assigning the database arrival time makes an old process condition appear current.

Ingestion time is still valuable. It can reveal delay, backlog recovery, or a gateway clock issue. Store or observe it separately when the design calls for it, rather than replacing the source time by default. If a payload has no trustworthy event time, document that the historian uses arrival time and that delayed data cannot be reconstructed precisely.

Apply tool mapping only after the contract is clear

TDengine TSDB Enterprise’s MQTT ingestion documentation describes topic analysis, a JSON extractor, and mappings for table names, supertable names, ordinary columns, and tag columns. It also provides mapping previews. Those features can implement a reviewed contract; they do not decide the contract for you. Configure and inspect sample messages that include normal values, a missing optional field, a malformed value, and a nested structure.

Avoid copying connector expressions from an example without checking the deployed version. Mapping behavior, template use, and any automatic schema evolution have operational consequences. Start with a bounded, explicit schema and use preview results to confirm each source field lands in the intended destination role. For a product overview of time-series storage and queries, see TDengine TSDB.

Verify with queries, not just a successful task state

Publish a small controlled set of messages for two distinct assets. Include a known timestamp, an expected unit, one null or missing optional field, and a value that should be rejected. Then verify:

- Each asset resolves to the intended table or source identity.

- Tags remain stable while measurement columns vary over time.

- Query results use the supplied event time and preserve the expected precision.

- Types, null handling, and quality values match the written mapping contract.

- A schema or parsing error is visible in the configured exception path rather than silently becoming a misleading record.

Repeat the check after a producer software update or a new asset type is introduced. The goal is not merely that JSON reaches a database. It is that every stored record remains attributable, correctly timed, typed, and usable in historical analysis.

Industrial AI is the use of artificial intelligence to support decisions and work in physical operations, such as manufacturing plants, energy facilities, warehouses, and infrastructure. It applies familiar AI methods, including machine learning, computer vision, and generative AI, to industrial data and workflows.

For an Industrial Digitalization Manager, the practical question is not whether a plant needs “AI.” It is whether a specific operational decision could be made faster, more consistently, or with better evidence. That might mean investigating abnormal equipment behavior, finding the right maintenance procedure, or monitoring a process for an emerging deviation.

Industrial AI, defined

Industrial AI applies AI technologies to real-world industrial operations and physical infrastructure. It can work with data from equipment, sensors, control systems, operational records, engineering documents, and other sources that describe how a site runs.

The goal is not necessarily autonomous control. Many useful applications help people investigate, compare, predict, summarize, or prioritize. A maintenance engineer may still make the final call. An operator may still follow an approved procedure. AI can support that work when it has relevant data, context, and clear limits.

What makes an AI application industrial?

An AI application becomes industrial because of the work it supports, not because it uses a unique category of algorithms. Its inputs and decisions relate to physical assets and processes: pumps, compressors, production lines, energy systems, material flows, or quality conditions.

That context matters. A temperature value needs an asset, unit, operating state, expected range, and related conditions before it can support a useful answer.

How Industrial AI differs from general enterprise AI

Enterprise AI often helps with digital business workflows, such as drafting documents, summarizing meetings, or answering questions about policies. Industrial AI can use similar language models and analytics techniques, but it is applied to operations where a decision may affect equipment condition, production quality, energy use, safety, or maintenance planning.

Not every Industrial AI application needs millisecond responses or direct access to a control system. But data can be noisy or incomplete, operating modes can change, and a useful conclusion may depend on engineering records or an experienced technician’s judgment. An AI-generated suggestion is not a substitute for site procedures or engineering review.

How Industrial AI works

Industrial AI usually combines three layers of work: data, context, and analysis.

Industrial data: signals, events, and operational records

The data layer may include time-series measurements, alarms, production records, inspection results, maintenance history, and engineering documents. Different sources often use different names, formats, and update rates. Collecting data does not automatically make it understandable.

Context: assets, relationships, and operating meaning

Context connects a data point to the industrial world. It can describe an asset hierarchy, the relationship between upstream and downstream equipment, the unit and expected range of a measurement, or the documents associated with a piece of equipment.

Context also includes operational knowledge, such as an earlier fault report, the checks performed, and its constraints. This helps an investigation move beyond finding a similar number or document title.

Analysis and human-reviewed action

With data and context in place, AI can support anomaly detection, forecasting, natural-language questions, document-based knowledge retrieval, or investigation. In many cases, the output is a recommendation for an engineer or operator to review, not an automatic command to equipment.

Three practical Industrial AI examples

Investigating an abnormal pump condition

A centrifugal pump shows unusual vibration. An investigation may compare its vibration and process signals with recent operating conditions, alarms, maintenance history, and relationships to related equipment. AI can help bring those sources together or highlight patterns worth checking. A reliability engineer reviews the evidence and decides whether maintenance work is needed.

Finding relevant maintenance knowledge

An engineer needs the approved procedure for an alarm code on a specific asset. Instead of relying only on keyword search, an AI-assisted workflow can use document content and equipment context to surface relevant manuals, troubleshooting records, and related knowledge. The engineer still verifies that the source applies to the current equipment and operating condition.

Monitoring a process for an emerging deviation

A team monitors a process variable against its normal operating pattern. A model may identify a deviation or forecast a future trend, giving the team a reason to inspect the process earlier. The finding should be evaluated with operating context, rather than treated as proof of a root cause.

What to establish before starting an Industrial AI project

Start with one operational decision, not a broad mandate to “use AI.” Define the user, evidence needed, and safe next step.

Then check four basics:

- Data: Is the relevant data available, timely enough for the task, and understood?

- Context: Can the team identify the asset, operating state, relationships, units, and related records behind the data?

- Governance: Who can access the information, and what sources should be treated as authoritative?

- Review: Who validates a finding, and which actions remain subject to normal engineering or operating procedures?

They help prevent a pilot from becoming an interface over incomplete or ambiguous information.

Where TDengine fits in an Industrial AI data foundation

TDengine’s Industrial AI platform brings together industrial data handling, analytics, modeling, visualization, and AI-oriented capabilities. Its Industrial AI page describes functions for asking questions about data, generating dashboards and analyses, detecting anomalies and forecasting behavior, and investigating events.

For operational context, TDengine’s Industrial Ontology is documented as a semantic layer for physical industrial assets, their data, and their relationships. It is different from TDengine IDMP’s Knowledge Graph, which organizes document-derived entities and relationships into a knowledge network.

Together, these documented capabilities can support workflows that connect time-series data, asset context, and documented knowledge. The design still depends on the decision, information quality, and review process.

Frequently asked questions about Industrial AI

Is Industrial AI the same as predictive maintenance?

No. Predictive maintenance is one possible use case. Industrial AI can also support process monitoring, quality investigation, engineering knowledge retrieval, operational reporting, and other tasks involving industrial data and context.

Does Industrial AI replace operators and engineers?

Not necessarily. Many Industrial AI applications are designed to support people by assembling evidence, identifying patterns, or making knowledge easier to find. Accountability for operational decisions remains with the people and procedures responsible for the work.

What data does Industrial AI need?

The answer depends on the use case. Start with data required for the decision, plus asset identity, units, operating condition, relationships, events, and supporting records. More data is not automatically better if its meaning and quality are unclear.

Historian data can support an Industrial AI model, but an export of tags and timestamps is rarely a training-ready dataset. Before data moves into an external model-training workflow, a historian engineer needs to establish what each measurement means, when it happened, which asset produced it, and whether the record is reliable enough for the task.

Start with the industrial decision, not the model. A team might want earlier warning of a pump condition or a better way to investigate recurring process deviations. Each goal requires different measurements, context, and evidence. A generic “AI dataset” usually creates more rows, not better training examples.

Start with the industrial decision, not the dataset

Define the asset or process, the decision the model is meant to support, and the time at which a prediction would be useful. Then identify what the model could legitimately know at that time.

For a centrifugal pump, the question might be: “Given the pump’s recent operating signals, should a reliability engineer review it?” That is different from asking a model to declare the cause of a failure. The first question can guide the selection of relevant historian measurements, operating states, alarms, maintenance records, and outcome labels.

This step also limits accidental leakage. A record created after a maintenance decision, for example, should not become an input if it would not have been available when the model is expected to make a prediction.

Check historian data quality before using it for AI

Review tag meaning, engineering unit, expected range, source system, and sampling behavior before treating historian data as model input. A tag named P_102 may be familiar locally but meaningless to a training workflow without asset identity and documentation.

Then separate different data conditions instead of calling them all “missing data”:

- A bad or invalid value may be a measurement-quality issue.

- A blank interval may mean the source was offline, the point was not collected, or the asset was not running.

- A delayed or replayed record may be valid but arrive after its event time.

- A repeated record may be a duplicate, or it may be two legitimate observations with the same value.

Treatment depends on the industrial question. Filling every gap can hide an outage; removing every unusual value can erase the event the model needs to learn from. Keep quality indicators and transformation reasons so the dataset remains reviewable.

Preserve timestamps and operating context

Time-series training depends on what happened when. Where it is available, preserve the source or event time separately from the ingestion time. Ingestion time can help explain delay or replay; it should not silently replace the time at which the process measurement occurred.

Operating context matters just as much. Link measurements to the correct asset, unit, operating mode, production state, and relevant events. A vibration value during startup may differ from one during stable production; a standby-pump pressure reading is not equivalent to one under load.

This is where asset context helps. TDengine’s Industrial Ontology describes a semantic layer for organizing industrial assets, data, and relationships. Whether a team uses that approach or another model, the training dataset needs enough context to explain what each record represents.

Make time-series data training-ready

Prepared historian measurements can become features and labels for an external model-training workflow. Features are the inputs available when a model makes a prediction. Labels are the outcomes the model is intended to learn or estimate.

For the pump example, features might include recent vibration, suction pressure, discharge pressure, flow, run/stop state, and calculated summaries over an agreed time window. An alarm is a label only when it represents the defined target outcome, such as whether a future alarm occurs, rather than duplicating alarm information already available in the features. Engineer-confirmed maintenance findings used as labels must likewise align with the intended prediction window. The label must be reliable enough for the task, and the features must be available before that outcome is known.

The time window, transformations, and label definition are task-specific. Do not assume one resampling interval, missing-value method, or split ratio suits every historian. Validation should keep future information out of model development and compare the model with data that represents the conditions it will face later. Depending on the operating pattern and available history, that may involve chronological holdouts, rolling evaluations, grouped periods, or another justified design. The important boundary is that future events, outcomes, and post-decision records do not leak into earlier examples.

Practical example: preparing pump historian data

Suppose a plant wants an external model to help flag pump conditions for review. The historian engineer begins with a set of pumps of the same type, not every tag in the plant.

They retain vibration, pressure, flow, run/stop state, alarm history, and reviewed maintenance events. They attach equipment identity and units, preserve event time, and flag periods affected by sensor problems, network gaps, or maintenance shutdowns. They then define a feature window that only uses signals available before the intended review point.

The maintenance record is not automatically a perfect label. It may describe a symptom, an inspection result, or an action taken for several reasons. The team should review whether it is specific enough to represent the outcome the model is meant to learn. This makes the model’s training data a traceable engineering artifact rather than a spreadsheet assembled after the fact.

How prepared historian data supports external model workflows

Once a dataset has defined features, labels, timestamps, asset context, and quality boundaries, it may be provided to an external training environment. That environment could train and evaluate a model using the team’s chosen tools and governance process.

The handoff should retain the data dictionary, transformations, time boundaries, quality rules, label definition, and source references. A later model result can then be compared with current historian data and reviewed by the appropriate engineer. Preparing data well does not guarantee a useful model, but it gives the team a clearer basis for testing one.

Where TDengine fits

TDengine’s Industrial AI page describes industrial data, analytics, visualization, and AI-oriented capabilities. Together with asset and relationship context from Industrial Ontology, these documented capabilities can support the data and context side of an Industrial AI workflow.

This article does not claim that TDengine trains or deploys external models. Model selection, training, evaluation, and deployment remain separate steps that require their own tools, validation, and operational approval.

Frequently asked questions

Can a historian export be used directly for model training?

Sometimes, but it should first be checked for meaning, units, timestamps, quality conditions, asset context, and the outcome being modeled. A flat export may be useful for exploration while still being unsuitable for a production-oriented evaluation.

Does more historian data always produce a better model?

No. More data can add value when it is relevant and reliable. It can also add noise, duplicates, unrelated operating states, or misleading records if the task and quality boundaries are unclear.

What should be retained with a trained model?

Retain the data definition, feature and label logic, transformations, quality rules, time boundaries, evaluation evidence, and the sources used to create the dataset. This gives later reviewers a way to understand what the model was tested against.

An Industrial Knowledge Graph organizes industrial context as connected entities and relationships. It can represent assets, processes, measurements, events, engineering documents, and operational knowledge. A pump may be linked to its measurements, a pressure fluctuation to a maintenance record, or a procedure to the asset type it applies to.

For an OT Architect, the point is to make scattered knowledge easier to find, inspect, and reuse in a defined operational workflow. That can give Industrial AI more relevant context than a raw document search alone.

Industrial Knowledge Graph, defined

An Industrial Knowledge Graph is a network of industrial knowledge. Its nodes represent identifiable knowledge items, such as equipment concepts, fault conditions, maintenance procedures, rules, documents, or events. Its links represent the relationships between them, such as causes, applies to, requires, or precedes.

The exact design varies by organization and product. Some approaches start with a formal model. Others derive relationships from existing information. The useful question is whether the graph helps people and systems follow a trustworthy path from an operational question to relevant evidence.

Why industrial context is hard to assemble

Industrial knowledge rarely lives in one application. A maintenance team may have an inspection report, alarm history, vendor manual, and previous fault investigation. Their connection may be implicit, documented in different terms, or known only by experienced staff.

An Industrial Knowledge Graph can make those connections explicit. It does not make every source correct, but provides a structure for relating knowledge, checking its source, and making it available to the next person facing a similar problem.

What an Industrial Knowledge Graph can connect

An Industrial Knowledge Graph may connect assets, processes, measurements, documents, procedures, events, calculations, engineering rules, and expert findings. The best scope depends on the decision it needs to support.

For example, a graph could link a compressor alarm to its troubleshooting procedure, its operating conditions, and earlier investigation records. This is more useful than a folder of PDFs when a user needs to understand why a procedure is relevant, not merely locate matching words.

The relationships are as important as the items themselves. They provide a path through the knowledge: a symptom may lead to a possible cause, a cause to a check, and a check to an approved action. That path can help an engineer review the evidence without treating an AI response as a final decision.

How an Industrial Knowledge Graph supports Industrial AI

Industrial AI needs context to answer a question about a plant or asset. A language model can summarize text, but may not know which maintenance record applies to an equipment type or how documented conditions relate. A Knowledge Graph can supply connected context for that task.

This can support three practical activities:

- Investigation: connecting symptoms, prior events, procedures, and supporting documents.

- Knowledge reuse: making an earlier, approved investigation easier to discover for similar equipment or conditions.

- Traceability: helping users inspect the knowledge path and source material behind a response.

The graph does not remove the need for governance. Teams still need to decide which documents are authoritative, how updates are handled, who can access information, and when an engineer must validate a recommendation.

Practical example: reusing a maintenance investigation

Consider a roller press that shut down after hydraulic pressure fluctuated. A maintenance record from that event includes the observed condition, a possible cause, the handling sequence, the pressure limit, and required spare parts.

In a Knowledge Graph, these can become connected knowledge items. The pressure fluctuation may be linked to the possible cause; the cause to the handling steps; and the steps to their constraints and required parts. The record can also be connected to the relevant roller-press type.

Later, a similar roller press shows the same pressure fluctuation. The graph can help a maintenance engineer find the earlier investigation and its documented reasoning. It does not prove that the new fault has the same cause. The engineer still checks the equipment, operating state, and approved procedure.

Industrial Knowledge Graph vs. Industrial Ontology

The two concepts are related and can work together. An ontology defines a domain’s concepts and relationships, such as asset types, measurements, and permitted relationships. A Knowledge Graph can use that ontology to organize connected facts and knowledge about those concepts.

This distinction matters for architecture, but it is not a universal separation. A graph of maintenance knowledge is not automatically a complete asset model, and an asset hierarchy does not automatically capture reasoning held in manuals or incident records. A team may use an ontology within its Knowledge Graph, then add both operational facts and documented knowledge to support a workflow.

Do not assume that products described as Knowledge Graphs, ontologies, semantic layers, or graph databases use the same architecture. A graph database, for example, is a technology for storing and querying graph-shaped data. It is not, by itself, a definition of the knowledge or physical-world model that data represents.

TDengine IDMP’s documented approach

TDengine IDMP documents an explicit distinction between Industrial Ontology and Knowledge Graph.

Its Industrial Ontology is a semantic layer for modeling the physical industrial world. It represents assets, data, relationships, and operational context that users configure and maintain.

Its Knowledge Graph documentation describes a document-based knowledge network. IDMP extracts entities and relationships from uploaded documents, then makes the resulting knowledge network available for queries and AI context.

This is one documented implementation, not a general definition of every Industrial Knowledge Graph. In TDengine IDMP, Industrial Ontology and document-derived Knowledge Graph are parallel semantic models with different sources and purposes. For broader operational context and AI capabilities, see TDengine’s Industrial AI overview.

Questions to ask before evaluating a Knowledge Graph approach

Start with the operational question. A useful first scope might be fault investigations for one asset class, rather than every document across every plant.

Then ask:

- Which documents and records are authoritative for this decision?

- Which entities and relationships must be represented for the workflow to be useful?

- How will the team review extracted knowledge, manage updates, and handle permissions?

- How will users see the underlying source material and validate a suggested knowledge path?

These questions keep a Knowledge Graph connected to an engineering or operations problem, rather than becoming a modeling project with no clear user.

Frequently asked questions about Industrial Knowledge Graphs

Is a Knowledge Graph the same as a graph database?

No. A Knowledge Graph is a way to organize knowledge and its relationships. A graph database can be one technology used to store or query graph-shaped data.

Is a Knowledge Graph the same as an ontology?

No. An ontology defines concepts and relationships for a domain. A Knowledge Graph represents connected facts and knowledge, and it can use an ontology as its conceptual model. They are related, not mutually exclusive.

Does a Knowledge Graph replace RAG or document search?

Not necessarily. Search and retrieval can still help locate relevant content. A Knowledge Graph adds explicit entities and relationships that can help connect knowledge across documents and make the context available for inspection.

An industrial data platform for AI should help a team assemble reliable, interpretable evidence for a defined operational decision. It is not simply a database, a historian replacement, or an AI application. When PLC, historian, IoT, and operational data live in different systems, the selection question is whether the platform can make the right data usable in the plant’s actual technical and operating environment.

Start with one decision. For example: should a reliability engineer review a compressed-air pressure drop within an hour, and which evidence is needed? That answer sets the required sources, history, context, access controls, and response time. It is a more useful starting point than a generic list of AI features.

Start with the operational decision, not the platform label

Map the evidence needed for the decision before evaluating products. PLCs may hold current control values and equipment states. A historian may hold years of pressure, flow, and power trends. IoT sensors can add vibration or environmental measurements. Maintenance and production systems may hold work records, equipment identity, or operating context.

These sources do not need to be replaced to support one AI-related use case. The key question is whether the required evidence can be found, understood, governed, and accessed together at the necessary time scale. A platform that connects many sources but cannot preserve meaning or make historical data usable may still create a difficult analytics project.

What an industrial data platform for AI needs to handle

Connect sources while preserving time and history

Ask which sources are relevant, how new data is brought in, and how historical records can be accessed. Preserve timestamps, source identity, engineering units, and the difference between a live state and a historical event. These details affect whether an engineer can compare a recent pressure drop with earlier operating periods.

Do not assume that a platform must replace an existing historian. A practical evaluation should establish how it can work with the systems that already hold trusted operational history and whether the required data can be accessed without creating unmanaged copies.

Add asset context and make governance reviewable

A pressure value is more useful when it is connected to the compressor, header, line, unit, and operating mode it describes. Industrial data contextualization is the work of attaching that meaning, including relationships and semantics, to raw records. Without it, each analytics or AI effort may have to recreate the same tag mappings.

During selection, ask how asset identity, units, limits, source definitions, quality flags, lineage, and permissions are maintained and reviewed. Industrial Ontology is one example of a semantic approach to organizing assets, data, and relationships. The right approach depends on who will maintain it and how it fits existing engineering practice.

Support analytics and external AI workflows

The platform should make approved data accessible for the analysis or external AI workflow the team actually plans to use. This does not require a claim that the platform trains or deploys a model. It means checking how authorized users or downstream tools can retrieve the necessary time-series history and context, and whether data definitions and transformations remain traceable.

The detailed preparation of historian data, including labels and validation, is a separate task. See How to Prepare Historian Data for Industrial AI Models for that workflow rather than treating platform selection as model development.

Validate performance, reliability, and recovery behavior

Expected workload is an evaluation input, not a marketing claim. Before a decision, define the anticipated number of sources, sampling rates, retention period, concurrent users, and historical query patterns. Then validate whether the proposed design meets the response time needed for the pilot’s real question.

Also ask how the platform behaves during network interruptions, service failures, restore operations, and planned maintenance. Clarify ownership for monitoring, backups, recovery tests, and confirmation that restored data and services are usable. Recovery behavior matters because a platform that cannot be operated and restored predictably may not be a reliable foundation for operational analysis.

Include implementation effort and total cost of ownership

Selection should account for more than license price. Compare the initial work to connect and map the required sources, infrastructure and deployment needs, ongoing maintenance, support responsibilities, and compatibility with the existing historian. A smaller first use case can expose these costs and responsibilities before the organization standardizes on a wider architecture.

Practical scenario: a compressed-air line pilot

Suppose a plant wants to investigate periods when header pressure falls while compressor energy use rises. The pilot needs PLC compressor state and control values, historian pressure, flow, and power trends, IoT vibration readings, and maintenance records.

The pilot should answer whether the team can investigate this bounded question more consistently. It should not be framed as proof of automatic root-cause analysis, fault prediction, or energy savings.

Where TDengine fits in the evaluation

TDengine Industrial AI describes a data foundation that combines industrial data, context, knowledge, and AI-oriented capabilities. TDengine IDMP documentation describes data ingestion from documented industrial and IT sources, an asset model, data contextualization, analytics, and connections to time-series or relational databases. These capabilities can be evaluated against the compressed-air pilot’s requirements.

The fit still needs to be checked at implementation level: the exact source protocol, deployment model, security boundary, data-access method, expected workload, recovery process, and operational owner. This article does not claim that TDengine replaces every historian or provides an external model-training or model-deployment workflow.

Frequently asked questions

Does an AI project require replacing the existing historian?

No. Start by identifying the evidence and access needed for the use case. The evaluation can then determine whether the existing historian should remain a source, integrate with another platform, or require a separate change.

Is a platform with more connectors automatically more AI-ready?

No. Connectivity matters, but so do historical access, context, quality, governance, performance, reliability, and the ability to support the intended workflow.

What should a first evaluation prove?

It should prove that a bounded team can access trustworthy, contextualized data for one real operational decision under the required workload, security, and operating conditions.

Plazenta: Das verkannte Organ. Zu wertvoll zum Wegwerfen?

Leipzig (ots)

Während der Schwangerschaft versorgt die Plazenta das ungeborene Kind mit Sauerstoff und Nährstoffen und schützt es vor zahlreichen schädlichen Einflüssen. Nach der Geburt wird das Organ häufig entsorgt. Dabei enthält die Plazenta Stammzellen, deren medizinisches Potenzial intensiv erforscht wird. Bei einem Pressegespräch von Vita 34 erklärten eine Hebamme, eine Ärztin und eine Naturwissenschaftlerin, warum die Plazenta mehr Aufmerksamkeit verdient und welche Möglichkeiten es gibt, ihr Gewebe für die Zukunft einzulagern.

Ein Organ für Mutter und Kind

Cathrin Klinkner begleitet als erfahrene Hebamme Frauen und Familien während der Schwangerschaft, bei der Geburt und im Wochenbett. In ihrem Vortrag zeigte sie, welche zentrale Rolle die Plazenta in dieser Zeit spielt. Die Plazenta entwickelt sich zu Beginn der Schwangerschaft und stellt die Verbindung zwischen Mutter und Kind her. Über sie erhält das ungeborene Kind Sauerstoff und lebenswichtige Nährstoffe. Gleichzeitig werden Stoffwechselprodukte des Kindes über die Plazenta an den mütterlichen Kreislauf abgegeben.

"Die Plazenta ist das einzige Organ im menschlichen Körper, das zwei Menschen gehört, nämlich Mutter und Kind", erklärte Cathrin Klinkner.

Dabei ist die Plazenta keineswegs nur eine einfache Verbindung. Sie wirkt auch als Schutzbarriere. Bestimmte mütterliche Antikörper können sie passieren und dem Kind in den ersten Lebensmonaten helfen, sich gegen Krankheitserreger zu schützen. Viele schädliche Keime und fremde Zellen werden dagegen zurückgehalten. Dieser Schutz ist jedoch nicht vollständig, weshalb die Gesundheit der Plazenta während der gesamten Schwangerschaft besonders wichtig ist.

Rauchen, eine unausgewogene Ernährung, Diabetes, Bluthochdruck, anhaltender Stress oder vorausgegangene Operationen an der Gebärmutter können die Entwicklung und Funktion der Plazenta beeinträchtigen. Für Cathrin Klinkner zeigt dies, wie wichtig es ist, das Organ während der Schwangerschaft bewusst wahrzunehmen: "Geben wir der Plazenta wieder die Bedeutung zurück, die sie verdient hat."

Stammzellen aus der Plazenta für die Zukunft bewahren

Eine Möglichkeit der Plazenta wieder mehr Bedeutung zuzumessen besteht darin, das Plazentagewebe nach der Geburt fachgerecht einzulagern. Darauf ging Dr. rer. nat. Bartel, Leiterin der Fachberatung bei Vita 34, ein. Die Plazenta enthält sogenannte mesenchymale Stammzellen. Das sind vielseitige Zellen, die sich unter bestimmten Bedingungen in verschiedene Zell- und Gewebearten weiterentwickeln können. Außerdem geben sie Botenstoffe ab, die Entzündungs- und Heilungsprozesse beeinflussen können. Deshalb sind sie für die Forschung an neuen regenerativen und immunologischen Therapien interessant. [1,2]

Da diese Stammzellen direkt nach der Geburt gewonnen werden, sind sie biologisch jung und vergleichsweise wenig durch Alterungsprozesse und Umwelteinflüsse belastet. Ihr möglicher therapeutischer Nutzen wird derzeit in frühen klinischen Studien untersucht. Dabei geht es beispielsweise um die Behandlung von schweren angeborenen Fehlbildungen, Schlaganfällen, Knorpelschäden und schweren Entzündungsreaktionen. Viele dieser Ansätze befinden sich noch in einem frühen Forschungsstadium und gehören nicht zur medizinischen Routineversorgung. [3-6]

"Die Plazenta bietet eine zusätzliche Zellquelle mit besonderem Potenzial für immunologische Anwendungen", erklärte Bartel.

Was geschieht sonst nach der Geburt mit der Plazenta?

Dr. med. Sophia Johnson beleuchtete beim Pressegespräch die kulturgeschichtliche Bedeutung der Plazenta und verschiedene Formen seiner nachgeburtlichen Verwendung. Die Plazenta produziert während der Schwangerschaft zahlreiche Hormone. Dazu gehören Östrogene, Progesteron und das sogenannte humane Plazentalaktogen, das unter anderem an der Vorbereitung der Milchbildung beteiligt ist. Untersuchungen zeigen, dass die Hormonmengen in roher, getrockneter oder anderweitig verarbeiteter Plazenta erheblich schwanken. [7-9]

Johnson sprach sich dafür aus, werdende Mütter sachlich über die verschiedenen Möglichkeiten zu informieren. Ihre zentrale Frage lautete: "Es ist meine Plazenta. Was mache ich damit?"

Plazentagewebe durch Kälte langfristig erhalten

Seit Sommer 2026 bietet Vita 34 neben der Einlagerung von Nabelschnurblut und Nabelschnurgewebe auch die private Einlagerung von Plazentagewebe an. Dabei wird das Gewebe nach der Geburt aufbereitet und bei sehr niedrigen Temperaturen tiefgefroren. Dieses Verfahren wird als Kryokonservierung bezeichnet.

Durch die Einlagerung sollen die im Gewebe enthaltenen Zellpopulationen und ihr biologisches Potenzial langfristig erhalten bleiben. So könnten sie grundsätzlich zur Verfügung stehen, falls sich später eine geeignete medizinische Anwendung ergibt. Ob und für welche Erkrankungen die eingelagerten Zellen tatsächlich eingesetzt werden können, hängt jedoch von der weiteren wissenschaftlichen Entwicklung und den künftig zugelassenen Therapien ab.

Vita 34 lagert nach eigenen Angaben das vollständige Plazentagewebe ein. Dadurch bleiben unterschiedliche Zellarten erhalten, die für mögliche zukünftige Anwendungen von Interesse sein könnten.

Weitere Informationen zur Einlagerung von Nabelschnurblut, Nabelschnurgewebe und Plazentagewebe finden Interessierte unter vita34.de.

_____________________________________________________________________________

Über Vita 34

Vita 34 ist eine Marke der FamiCord AG. Die FamiCord AG ist ein 1997 gegründetes Unternehmen mit Sitz in Leipzig und ist nicht nur die führende Stammzellenbank Europas, sondern auch die drittgrößte weltweit. Angetrieben durch den Leitgedanken, allen Menschen eine gesündere Zukunft zu ermöglichen, erbringt die FamiCord AG als Full-Service-Anbieter mit weltweit rund 800 Mitarbeiter:innen alle Leistungen rund um die Gesundheitsvorsorge mit Nabelschnurblut, Nabelschnurgewebe und Plazenta.

_____________________________________________________________________________

Referenzen

- Davies JE, Walker JT, Keating A. Stem Cells Transl Med. 2017;6(7):1620-1630.

- Galieva LR, et al. Front Pharmacol. 2017 Sep 8;8:628.

- Farmer DL, et al. Lancet. 2026 Feb 28;407(10531):867-875.

- Human Placenta-derived 3D Mesenchymal Stem Cells (Guojianqingke) (3D MSC - QK01); https://clinicaltrials.gov/study/NCT07635758. Letzter Zugriff Oktober 2026.

- Safety and Efficacy of hUC-MSC for the Treatment of Cartilage Damage in the Knee Joint (BPCC001); https://clinicaltrials.gov/study/NCT06981741. Letzter Zugriff Oktober 2026.

- Umbilical Mesenchymal Stromal Cells as Cellular Immunotherapy for Septic Shock (UC-CISSII); https://clinicaltrials.gov/study/NCT05969275. Letzter Zugriff Oktober 2026.

- Reis FM, Petraglia F. Front Horm Res. 2001;27:216-228.

- Johnson et al. Placenta. 2018;67:8-14.

- Chang S. et al. Placenta. 2017;60:100-102.

Pressekontakt:

Benedikta Springer

dpmed GmbH

Tel: +49 89 71 67 231 - 10

Mobil: +49 171 - 790 26 42

E-Mail: benedikta.springer@dpmed.de

Original-Content von: VITA 34, übermittelt durch news aktuell

Bruttosparquote in Deutschland mit 18,9 % im internationalen Vergleich überdurchschnittlich hoch

WIESBADEN (ots)

Private Haushalte in Deutschland sparen anteilig mehr als in vielen anderen Industriestaaten. Mit 18,9 % lag die Bruttosparquote im Jahr 2025 deutlich über dem Durchschnitt in der Europäischen Union von 14,3 %, wie das Statistische Bundesamt (Destatis) zum Weltspartag am 30./31. Oktober mitteilt. In Frankreich sparten die privaten Haushalte 17,8 % ihres verfügbaren Bruttoeinkommens, in den Niederlanden 17,4 %, in Österreich 15,7 % und in Italien 10,8 %. Einen deutlich höheren Wert unter den international mit Deutschland vergleichbaren Staaten wies die Schweiz mit 27,4 % aus, was an der dortigen höheren Bedeutung der privaten Altersvorsorge liegt. Vergleichsweise niedrig war die Bruttosparquote dagegen mit 10,7 % in den Vereinigten Staaten.

Die Bruttosparquote wird üblicherweise für internationale Vergleiche genutzt. Sie weist den Anteil des Gesparten am verfügbaren Einkommen der privaten Haushalte vor Abzug von Abschreibungen, vor allem auf Immobilien, aus.

Haushalte in Deutschland neigten auch in den Vorjahren stärker zum Sparen

Auch in einer langfristigen Betrachtung zeigt sich die hohe Sparneigung der Haushalte in Deutschland. In den letzten zehn Jahren sparten die Haushalte im Durchschnitt 19,1 % ihres Einkommens. In Frankreich war der Anteil mit 16,6 % geringer, ebenso in den Niederlanden (16,3 %), in Österreich (15,3 %), in Italien (12,1 %) und in den Vereinigten Staaten (13,0 %). In der Schweiz war die Bruttosparquote im Durchschnitt der Jahre 2016 bis 2025 dagegen höher (24,5 %).

Zuletzt ging die Sparquote in Deutschland leicht zurück. Im ersten Halbjahr 2026 lag sie wie im gesamten Jahr 2025 bei 18,9 %. Im Jahr 2024 hatte sie bei 19,6 % gelegen. Einen Höchststand hatte sie im Jahr 2020 mit 22,9 % erreicht. Während der damals herrschenden Covid-19-Pandemie konsumierten die Menschen weniger als gewöhnlich, was zu einem Anstieg der Sparquote führte.

Methodische Hinweise:

Die in den Volkswirtschaftlichen Gesamtrechnungen ermittelte Sparquote ergibt sich aus dem Sparen aller privaten Haushalte gemessen an ihrem verfügbaren Einkommen insgesamt, einschließlich neu erworbener betrieblicher Versorgungsansprüche. Bewertungsbedingte Änderungen wie Kursgewinne oder -verluste bei Aktien und Wertänderungen bei Immobilien zählen weder zum Sparen noch zum Einkommen. Der durch Abschreibungen ausgedrückte Verzehr von Werten - bei privaten Haushalten sind dies vor allem Abschreibungen auf selbst genutzte und vermietete Wohnungen - ist bei der Bruttosparquote nicht abgezogen. Bei der Bruttosparquote sind die Abschreibungen sowohl im Einkommen als auch im Sparen enthalten. Bei der Nettosparquote sind diese Abschreibungen abgezogen, d.h. sie reduzieren das verfügbare Einkommen privater Haushalte und damit auch deren Sparen. Der Wert für die Nettosparquote liegt daher deutlich unter dem der Bruttosparquote.

Die Daten zu Sparquoten stammen von der EU-Statistikbehörde Eurostat, von der OECD (Vereinigte Staaten) und von nationalen statistischen Ämtern (Deutschland, Frankreich, Schweiz). Insbesondere für das Jahr 2025 und das 1. Halbjahr 2026 sind sie noch vorläufig.

Weitere Informationen:

Weitere Daten zu Sparquoten in der EU gibt es im Webangebot der europäischen Statistikbehörde Eurostat und darüberhinausgehende internationale Daten bei der OECD.

Diese Zahl der Woche ist, gegebenenfalls ergänzt mit weiteren Informationen und Verlinkungen zum Thema, veröffentlicht unter www.destatis.de/pressemitteilungen.

Weitere Auskünfte:

VGR Verteilungsrechnung

Telefon: +49 611 75 2218

www.destatis.de/kontakt

Pressekontakt:

Statistisches Bundesamt

Pressestelle

www.destatis.de/kontakt

Telefon: +49 611-75 34 44

Original-Content von: Statistisches Bundesamt, übermittelt durch news aktuell

Deutsche Glasfaser Holding GmbH

Connect zeichnet das Netz von Deutsche Glasfaser 2026 mit der höchsten Punktzahl in Deutschland aus

Düsseldorf (ots)

- 963 von 1.000 Punkten: Deutsche Glasfaser erzielt die höchste Punktzahl aller getesteten regionalen und nationalen Anbieter in Deutschland.

- Testsieg für Deutsche Glasfaser: Zum vierten Mal seit 2022 ist das Unternehmen regionaler Spitzenreiter im connect-Festnetztest

- Spitzenwerte in wichtigen Kategorien: Das Netz überzeugt insbesondere bei Verbreitung und Upload-Datenrate. Auch bei der Zuverlässigkeit erhält Deutsche Glasfaser die Bestnote "überragend".

Deutsche Glasfaser ist erneut Testsieger regional im Festnetztest des Telekommunikationsmagazins connect. Mit 963 von 1.000 möglichen Punkten erzielt das Unternehmen die höchste Gesamtpunktzahl aller in Deutschland getesteten Anbieter. Damit bestätigt Deutsche Glasfaser zum vierten Mal nach 2022, 2024 und 2025 seine Spitzenposition im renommierten Qualitätsvergleich. Im Vergleich zum Vorjahr konnte Deutsche Glasfaser seine Bewertung auf Basis der vergebenen Basispunkte nochmals verbessern.

"Die Auszeichnung durch connect ist eine wichtige Bestätigung unseres Anspruchs, unseren Kunden und unseren Partnern eine leistungsfähige und zuverlässige digitale Infrastruktur zu bieten. Denn Netzqualität entscheidet darüber, ob Menschen im Alltag reibungslos arbeiten, lernen, kommunizieren und digitale Angebote nutzen können. Dass wir im bundesweiten Vergleich die höchste Punktzahl erreichen, den Testsieg regional davontragen und unser Netz als "überragend" ausgezeichnet wird, ist eine tolle Bestätigung für unsere Arbeit und eine große Motivation für unser Team bei Deutsche Glasfaser", sagt Gerhard Mack, Chief Operating Officer der Deutsche Glasfaser Unternehmensgruppe.

Besonders stark schneidet Deutsche Glasfaser in den Kategorien Verbreitung und Upload-Datenrate ab. Darüber hinaus erhält das Unternehmen zum dritten Mal die Auszeichnung "überragend" - auch die Zuverlässigkeit des Netzes wird mit "überragend" bewertet.

Der aktuelle Erfolg reiht sich in eine Serie ausgezeichneter Testergebnisse ein: Auch der Test des Technikmagazins CHIP bestätigt die hohe Qualität des Netzes: Im Mai 2026 wurde Deutsche Glasfaser zum fünften Mal in Folge als bester regionaler Anbieter ausgezeichnet.

Über den connect-Festnetztest

Der Festnetztest von connect zählt zu den renommiertesten Qualitätsvergleichen der Telekommunikationsbranche in Deutschland. Die Auswertung basiert auf einer Crowdsourcing-Analyse von Messdaten, die an den Endgeräten der Internetanschlüsse erhoben werden. Für den diesjährigen Test flossen Daten aus 1.039 Millionen Messungen von 3.108.073 berücksichtigten Internetleitungen ein. Der Analysezeitraum umfasste 24 Wochen von Mitte April bis Ende September 2026.

Die Unternehmensgruppe Deutsche Glasfaser hat in den drei deutschen Stadtstaaten kein aktives Netz und wird im Test als Regionalanbieter eingestuft.

Pressekontakt:

Dominik Beyer

Deutsche Glasfaser Unternehmenskommunikation

presse@deutsche-glasfaser.de

Original-Content von: Deutsche Glasfaser Holding GmbH, übermittelt durch news aktuell

TÜV Mobility Studie: Große Mehrheit für null Promille am Steuer

Berlin (ots)

71 Prozent befürworten ein absolutes Alkoholverbot für Autofahrende, fast jede zweite Person für alle abgefragten Fahrzeugarten. TÜV-Verband fordert null Promille für alle Kraftfahrzeuge und strengere Regeln für Radfahrende.

Sieben von zehn Bundesbürger:innen (71 Prozent) befürworten ein absolutes Alkoholverbot für Autofahrer:innen. Für Motorräder, Motorroller, Mopeds und Mofas liegt die Zustimmung bei 74 Prozent und für E-Scooter bei 67 Prozent. Auch beim Fahrrad ist eine knappe Mehrheit (54 Prozent) für null Promille. Fast jede zweite befragte Person (49 Prozent) unterstützt die Nullpromillegrenze sogar für alle abgefragten Fahrzeugarten. Knapp jede:r fünfte Befragte (18 Prozent) lehnt die Nullpromillegrenze komplett ab. Das zeigt die TÜV Mobility Studie 2026, für die forsa im Auftrag des TÜV-Verbands 2.504 Personen ab 18 Jahren befragt hat.

"Alkohol greift genau das an, was man zum sicheren Fahren braucht: klaren Blick, Konzentration und schnelle Reaktion", sagt Fani Zaneta, Referentin für Fahrerlaubnis, Fahreignung und Verkehrssicherheit beim TÜV-Verband. "Deshalb muss für alle, die ein Kraftfahrzeug fahren, null Promille gelten. Alkohol muss aus dem Straßenverkehr verbannt werden." Um wiederholte Alkoholfahrten zu verhindern, fordert der TÜV-Verband zudem, die Medizinisch-Psychologische Untersuchung (MPU) bereits ab 1,1 Promille anzuordnen statt wie bisher in der Regel ab 1,6 Promille.

Frauen und Ältere häufiger für absolutes Alkoholverbot

Frauen sprechen sich deutlich häufiger für ein Alkoholverbot aus als Männer: 78 Prozent der Frauen und 63 Prozent der Männer befürworten null Promille für Autofahrende. Ein Alkoholverbot für alle Fahrzeugarten unterstützen 57 Prozent der Frauen, aber nur 40 Prozent der Männer. Männer (24 Prozent) lehnen ein Alkoholverbot insgesamt doppelt so häufig ab wie Frauen (12 Prozent).

Noch stärker als zwischen den Geschlechtern gehen die Meinungen zwischen den Altersgruppen auseinander: Ein absolutes Alkoholverbot für alle Fahrzeugarten unterstützen 31 Prozent der 18- bis 29-Jährigen, 47 Prozent der 30- bis 44-Jährigen, 48 Prozent der 45- bis 59-Jährigen und 59 Prozent der Menschen ab 60 Jahren. Die Nullpromillegrenze für Autofahrer:innen befürworten 78 Prozent der Befragten ab 60 Jahren, aber nur 62 Prozent der 18- bis 29-Jährigen.

Gefahr bekannt, Grenzwerte trügerisch

Dass Alkohol am Steuer gefährlich ist, wissen fast alle: 86 Prozent der Befragten halten ihn für sehr gefährlich, 12 Prozent für eher gefährlich. Tatsächlich erhöhen schon geringe Mengen das Unfallrisiko deutlich. Nach Daten des European Road Safety Observatory (ERSO) ist das Risiko, an einem tödlichen Unfall beteiligt zu sein, bei 0,3 Promille fast doppelt so hoch wie in nüchternem Zustand. Das allgemeine Unfallrisiko liegt bei 0,5 Promille beim 1,4-Fachen.

TÜV-Verband fordert klare Regeln für mehr Verkehrssicherheit

In Deutschland dürfen Kraftfahrzeugfahrende grundsätzlich mit bis zu 0,5 Promille fahren. Null Promille gilt bisher nur für Fahranfänger:innen in der Probezeit und für unter 21-Jährige. Zeigen Fahrende alkoholbedingte Ausfallerscheinungen, kann schon ab 0,3 Promille eine Straftat vorliegen. Ab 1,1 Promille gelten sie als absolut fahruntüchtig, Radfahrende erst ab 1,6 Promille. "1,6 Promille sind ein ausgewachsener Rausch", sagt Zaneta. "Wer so viel getrunken hat, kann kein Fahrzeug mehr sicher führen, auch kein Fahrrad. Dass das Recht Radfahrenden hier so viel Spielraum lässt, passt nicht zum Risiko." Nach Ansicht des TÜV-Verbands besteht hier dringender Handlungsbedarf und empfiehlt die Grenze der absoluten Fahruntüchtigkeit für Radfahrende von 1,6 auf 1,1 Promille zu senken. Zudem sollte ein eigener Bußgeldtatbestand für alkoholisierte Radfahrende eingeführt werden.

Methodik-Hinweis: Grundlage der Studienergebnisse ist eine repräsentative Forsa-Umfrage im Auftrag des TÜV-Verbands unter 2.504 Personen ab 18 Jahren. Die Umfrage wurde vom 19. März bis 10. April 2026 durchgeführt.

Über den TÜV-Verband: Als TÜV-Verband e.V. vertreten wir die politischen Interessen der TÜV-Prüforganisationen und fördern den fachlichen Austausch unserer Mitglieder. Wir setzen uns für die technische und digitale Sicherheit sowie die Nachhaltigkeit von Fahrzeugen, Produkten, Anlagen und Dienstleistungen ein. Grundlage dafür sind allgemeingültige Standards, unabhängige Prüfungen und qualifizierte Weiterbildung. Unser Ziel ist es, das hohe Niveau der technischen Sicherheit zu wahren, Vertrauen in die digitale Welt zu schaffen und unsere Lebensgrundlagen zu erhalten. Dafür sind wir im regelmäßigen Austausch mit Politik, Behörden, Medien, Unternehmen und Verbraucher:innen.

Pressekontakt:

Marie Claire Buschbaum

Presse und Kommunikation

TÜV-Verband e. V.

Friedrichstraße 136 | 10117 Berlin

030 760095-320, presse@tuev-verband.de

www.tuev-verband.de | www.linkedin.com/company/tuevverband

Original-Content von: TÜV-Verband e. V., übermittelt durch news aktuell

PNCC Safeguards Voice Networks in Palau with Telecoms Fraud Prevention Solution from Oculeus

Oculeus AFS provides dedicated anti-fraud layer to protect PNCC's subscribers and commercial operations against new and ongoing telecoms fraud threats

FRANKFURT, Germany, Oct. 27, 2026 /PRNewswire/ -- Oculeus, a leading provider of innovative software solutions for telecommunications service providers, today announced that the company has deployed its Oculeus Anti-Fraud System (AFS) for Palau National Communications Corporation (PNCC), the national telecommunications provider of the Republic of Palau.

PNCC provides mobile, fixed, broadband and international connectivity services nationwide to residential and business customers. The company operates Palau's domestic fiber-optic backbone and is currently modernizing the country's mobile infrastructure.

In common with other Pacific Island nations, PNCC faces unique challenges to its network and is fully committed to protecting its infrastructure against global scam activities and unauthorized international routing schemes that target local consumers.

Oculeus AFS provides PNCC with a dedicated solution to protect its voice network infrastructure by rapidly identifying and blocking such attacks before subscribers and operations are impacted. Oculeus AFS leverages artificial intelligence (AI) and machine learning (ML) together with anomaly detection to analyze large volumes of telecommunications activity and mitigate fraudulent or abusive traffic in near-real-time. PNCC is using the system in a way that maximizes its automation features and allows the company to apply effective anti-fraud protections.

"As we further modernize Palau's communications infrastructure, maintaining the highest standards of network integrity is our top priority," stated Simon Fraser, CEO at PNCC. "We selected the Oculeus solution as it combines the latest technology with a competitive and accessible pricing model, backed by the reassurance of an existing worldwide customer base. The solution also brings great automation benefits and allows us to enhance operational resilience by utilizing and upskilling our existing team."

"PNCC has a strong regional reputation for its culture of innovation and we are proud to be contributing to the company's ambitious development," said Arnd Baranowski, CEO of Oculeus. "We are also pleased to be expanding our presence in the South Pacific, helping to show how small telcos around the world can leverage cutting-edge technology to protect their operations and customers against complex telecoms fraud threats."

About Oculeus

Oculeus is a leading provider of innovative software solutions for telecommunications service providers, network operators and other providers of voice and messaging services. The company's product portfolio includes solutions for interconnect wholesale management, retail voice management and telecommunications fraud protection. Oculeus' AI-driven solutions utilize state-of-the-art technologies for service providers to build and maintain efficient and highly automated network and business operations. Oculeus has been serving customers worldwide since 2004 as a technology partner and strategic vendor. For more information, please visit www.oculeus.com.

About Palau National Communications Corporation

Palau National Communications Corporation (PNCC) is the national telecommunications provider of the Republic of Palau, delivering mobile, fixed, broadband and international connectivity services nationwide. The company was established in 1982 and is a state-owned corporation. For more information, please visit www.pnccpalau.com.

Press Contact

[email protected]

SOURCE Oculeus

Share this article