Advancing Digital Twinswith Data Modeling
Use data product practices
to provide simple accessand governance of industrial data
across source data models,domain data models,and solution data models

Advancing Digital
Twins with Data
Modeling
Use data product practices to provide
simple access and governanceof industrial data across source data
models, domain data models,and solution data models

Table of contents
Executive summary........................................................................................................................... pg. 3
The industrial data problem............................................................................................................. pg. 4
From siloed industrial data to a Digital Twin.................................................................................... pg. 5
The origins of "Data as a Product"................................................................................................... pg. 7
DataOps evolves................................................................................................................................ pg. 7
Industrial data products are complex.............................................................................................. pg. 8
Data models to the rescue............................................................................................................... pg. 10
Domain data models......................................................................................................................... pg. 11

About Cognite

Consuming data................................................................................................................................ pg. 12

Cognite is a global industrial SaaS company that
supports the full-scale digital transformation ofasset-heavy industries around the world. Our core
Industrial DataOps platform, Cognite Data Fusion®,enables data and domain users to collaborate toquickly and safely develop, operationalize, andscale industrial AI solutions and applications.

Onboarding data ............................................................................................................................... pg. 13©COGNITE 2023 — COGNITE.COM

2

Cognite Data Fusion®’s data modeling architecture...................................................................... pg. 15

Cognite Data Fusion® codifies industrial domain
knowledge into software that fits into your existing
ecosystem and enables scale from proofs ofconcepts to truly data-driven operations to deliver
both profitability and sustainability.
WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →Executive summary
To increase the impact industrial digital twins haveacross operations, industry focus must shift tothe data integration layer that powers digital twins.
Today, much of our industrial data is still siloed, difficult to understand, and used by very few stakeholders in business. For this to change, digital twins
must easily integrate all industrial data, provide
simple access to this data, and accelerate thedeployment and scaling of solutions.

siloed data into scalable solutions. Below is thedata modelling framework Cognite Data Fusion®
uses to power our Open Industrial Digital Twin:■ Solution data models. Data from the sourceand domain models can be reused to deploy andscale solutions.

■ Source data models. Data is liberated fromsource systems and made available in its original state.

With Cognite Data Fusion®, data from all industrial
sources can be integrated, contextualized, andscaled to solve challenges across asset performance, production optimization, product quality,
and more.

■ Domain data models. Siloed data is unified
through contextualization and structured into
industry standards.

Data modelling is a core component of turningRAW

Apps, solutions, use cases etc.

Domain data model

Source data model

Asset or process centric – Follow standards(e.g. OPC, ISA95) – Custom semantic types (CNC)

Asset hierarchy from SAP – OPC from Kepware– BOP/BOM from MES
Liberate data in source systems by having them modeled
and queryable in Cognite Data Fusion® through the same
API interfaces.

WHY COGNITE DATA FUSION® →Domain data models are optimized for reuse between application
developers, data scientists and solution developers. We offer a
set of industry standard OOTB data models that can be extended.

BENEFITS FOR YOUR TEAMS →CONTACT SALES →Solution data model

Data model targeting data consumption for use cases
Optimized data models for applications, data scientists and othersolutions. We provide a GraphQL interface with auto generated
SDKs for minimal code. This provides Backend as a Service (BaaS)
to reduce cost of development and maintenance of solutions.

©COGNITE 2023 — COGNITE.COM

3

Source systems

The industrial data problem

WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →4

These questions are the concerns of the subject
matter experts, the engineers responsible for keeping equipment running and continuously operating
at a level that maximizes efficient production both
short-term and long-term. Increasingly, documentation and electronic trails of maintenance and operational history can be accessed digitally. However,diagrams and vendor documentation are still foundin flat PDF files, maintenance records are scanned
paper documents, and 3D models are not up-todate with the actual physical world as modifications
and maintenance happen. How do we enable subject
matter experts across operations, maintenance,and quality to solve their problems with digital tools?
Data science models combined with physical simulators promise huge optimisations. Yet, you will alsoneed to move beyond the constraints of the vendors’
models and tie together sensor data from your end
to end operations with models that can predict fault
situations or optimize your production.

Herein lies a fundamental question; You canstore all this industrial data in databases, but
how do you access information and understand the relationship between two physicalcomponents that are found in a PDF diagram?
It could be as simple as a maximum pressure recommendation, or the last maintenance report. Finding the right informationand enough context to understand what you
are looking at is not as simple as using Google
search. You need a much richer, contextual
picture to understand what is going on, whatmight be the problem, and how it can be solved.

©COGNITE 2023 — COGNITE.COM

The physical world of industrial data is a messy
place. Equipment wear, fluctuating operationaltargets, and work orders are all important factors
in determining the cause of operational issues. A
process value cannot be observed and interpreted
in isolation. Is our value too high? What is the maximum pressure recommended by the vendor? Are
there any deviations from the recommended value?
When was this pump last inspected and what were
the observations?

CONTACT SALES →From siloed industrial data to a Digital Twin
Instrumentation Diagram, P&ID). If you are looking
into a problem with a pump operations andstarting out from a view where you are inspecting
the time series sensor values coming from thepump, the latest work order on the pump and themaintenance report is critical to your problem
solving. Since the maintenance report, the workorder, and the time series sensor values are often
found in separate systems, it is not a trivial task

to gather all the relevant information necessary.
This simple example above illustrates the importance of data contextualization across different
systems.
Cognite Data Fusion® allows industrial companies
to represent these real-world components, how
they relate to each other and their exact location,
as well as all the possible connections that are5

At the core of the problem is what we call “contextualization”. Time series sensor values like [1.1, 1.2,
1.3, …] have little meaning without knowing fromwhich equipment the sensor values are collectedfrom and the wider context of the process thisequipment is a part of. Also, other data like theunit of the sensor values, fault state of the equipment, nearby sensor values, connected equipment, maintenance history, and other data canbe essential to interpreting the sensor values andfinding the root cause of an operational issue.
Contextualization is the process of establishing
meaningful relationships between data sources
and types to traverse and find data through adigital representation of the relationships thatexists in the physical world. Through contextualization, you build what we refer to as an industrial
knowledge graph. This knowledge graph is continuously evolving and spans many dimensions anddifferent data types, from the time series values
to diagrams showing the process flows to a nodein, e.g., a facility 3D model and recent images froman inspection.

WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →©COGNITE 2023 — COGNITE.COM

The diagram below illustrates a simplified versionof an industrial knowledge graph of a centrifugal
pump.. Depending on where you are starting to
explore a problem with the centrifugal pump, you
may start from the maintenance report (whichshows a deviation) or maybe from the workorder or the engineering diagram (e.g. Piping and
CONTACT SALES →created, changed, and augmented throughout
the lifespan of the components and the asset.
The type of data that needs to be connected issomewhat stable, but the data itself is continuously generated by disparate systems and thedata needs to be continuously contextualized tomake all data accessible for problem solving.
However, there is another complexity that alsocomes into play. The diagram above shows someobvious connections between different data
relevant to the operations, but what if the pumpis replaced with a newer version that offers moresensor values? To use this new sensor, you needto add a new sensor value to the data model ofthis pump. Can you do this without breaking thedashboard you created to monitor operations of
all similar equipment?

graph that can present different industrial digital
twins adapted to your needs is important, but it isunfortunately not the only thing you need to solve
operational problems with your vast amounts ofindustrial data. Many ambitious projects fail to try
to structure data into a common model that canbe used by all data consumers.. The data is there
and you can find it, but can you trust the data?
Do you have robust data pipelines and change
management in place to ensure reliability? Are
you able to evolve your digital twin representation
with the life cycle of the assets or when new datais needed for more valuable insights? Have you
used an industry-standard to represent your data,and can you share the data with your vendors andpartners? And how do you handle the information©COGNITE 2023 — COGNITE.COM

Having all your data in an industrial knowledge
WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →To tackle these problems, you need to actively
control, monitor, and manage the data througha governance and management process. This isa continuous process to ensure that data does
not become stale and unusable, and that data isproperly governed and secured. When you treat
data as a product in your organization - and proactively make it available and valuable for everyone
in your organization - you are practicing DataOps,
or rather Industrial DataOps. Industrial DataOps
is about breaking down silos and optimizing thebroad availability and usability of industrial data,
specifically in asset-heavy environments.

6

A continuously evolving industrial knowledge
graph is the foundation of creating industrial
digital twins that solve real-world problems.
Industrial digital twins are powerful representations of the physical world that can help you
better understand how your assets are impacting
your operations. A digital twin is only as useful as
what you can do with it, and there is never only
one all-encompassing digital twin. Your maintenance view of a physical installation will need tobe different from the operational view, which isdifferent from the engineering view for planningand construction.

you need that has no representation in industry
standards such as CFIHOS or ISA:95?

CONTACT SALES →The origins of "Data as a Product"

The often-overlooked problem of making reliable,
clean data available for analysis is complex, evenfor a marketplace like eBay. Who bought what? To
be shipped where? Is the shipping address valid?
Can we see purchasing trends by region? How can
we predict how big the Black Friday sales will be?
Just like industrial organizations, companies likeeBay, Über, and Netflix have a size and complexitythat makes such questions hard to answer. To
WHY COGNITE DATA FUSION® →increasing number of requests for running ananalysis and presenting the results. The businessside was the "buyers" of the data product, andthe data experts packaged the data and made it
self-service. This Data as a Product concept is also
applicable in our complex industrial environments.

The internal users of the data used tools like
Tableau and custom-made dashboards. The dataexperts who offered the data as a product built
more powerful and flexible tools to cater to an

DataOps evolves
The data experts started to evolve a setof practices to continuously improve thedata products and make small, incremental
changes as they learned what the businessneeded.
For example, an error in a service handlingmovie recommendations could result in a loss
in the data that showed how many times acertain movie was recommended per hour,per day, to which region, etc. Fixing that error
could dramatically improve the data quality and

BENEFITS FOR YOUR TEAMS →CONTACT SALES →thus every decision where you needed to know
these specific statistics. Solving challenges
like this led to the DataOps practice, named assuch because DataOps merges the operationsof supplying the data with the understanding of
the data and how it should be improved as one
feedback loop to iterate and improve quickly. In
this way, DataOps does for data what DevOps
does for development – merging operations andcreation, for rapid feedback loops and frequent
iterations to drive improvement.

7

These two domains have traditionally not collaborated closely. And unfortunately, industrial data
is not readily available directly from the sources
and cannot be easily consumed by domain
experts. The data may not have been cleaned,verified, approved, guaranteed, or transformed.
Additionally, it may not even be understandable
without operational context. All these steps
are needed for domain experts to solve business problems, but they don't have the tools tocomplete these steps with the data on their own.
Additionally, it is often challenging for domain
experts to communicate their needs to softwareand data experts.

scale data management and dynamically answer
new questions, early ideas of “Data as a Product”
were pioneered by the aforementioned companies to allow finance, sales, and other internal
operational departments to quickly answer newquestions by combining streams of data comingfrom operations.

©COGNITE 2023 — COGNITE.COM

Solving the most valuable and complex problems in the industry is particularly challenging
because it requires both industrial domain
experts to understand the problem and dataengineering experts to provide simple accessand governance of industrial data.

Industrial data products are complex
In the traditional technology domains mentioned
above, the data experts can understand the data
and determine whether the data makes senseor has issues. They also partially understand the
problems that the finance or operations people
want to answer. In an industrial context, data isharder to control and understand.

1. The interactions and iterations needed between
the data expert and the domain expert are
higher.

data of a physical asset or system that you needto study to extract the full value in order to solve
particular process problems.

2. Determining the usefulness and quality ofa specific piece of data requires a lot more
context.

To give an example, values from a thermometercan be in Celsius, Kelvin, or Fahrenheit, and in
one context a value above 1,000 can be within an
acceptable range, but in another context the value
does not make sense or indicates a fault. Anotherexample, two pieces of the same equipment canbe slightly different within the same factory floor.
A maintenance operation done on one piece ofequipment can impact the calibration of another.

This context can be found by looking at the total
spectrum of information related to the equipment you want to study. Pieces of information
exist within PDF documents, databases storing
work orders for maintenance, machine-generated events that have been registered, imagery
data from the last inspection, the 3D model of thesystem, and a myriad of other data.

Below is a simple example of a data product where
the inlet pressure from the centrifugal pump ispresented together with a (theoretical) calculated
maintenance prediction estimating the likelihoodof failure from 0 to 100. The prediction may be basedon the inlet pressure, how that compares to thevendor’s recommended range, the maintenancerecord, and other factors (to simplify, not everything that is part of the data product is shown in the
diagram below). Of course, if the pump is replacedwith a version with a slightly different specification,
this should not mean that you have to create a new
prediction model. The model should automaticallypick up the latest specifications and calculate an
appropriate maintenance prediction. This is easier
said than done and DataOps and Data as a Productalone is not enough.

©COGNITE 2023 — COGNITE.COM

8

All these physical world realities lead to two major
implications:

To be useful for solving problems, industrial data
products require data from many different source
systems to be connected to reflect the physicalworld. It must include historical and operational

WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →©COGNITE 2023 — COGNITE.COM

9

How do data products relate to the digital twin?
Conceptually (and visually), you can think about
live data “streaming'' through the digital twin, each
set of streams governed and managed so you
can trust the data. Imagine operational failures
lighting up in color in your 3D model or seeing live
sensor values in your engineering diagram while
you quickly click through to related sensor values
or data. Using your data product, you run simulations and analytics and create data sciencemodels that predict upcoming failures or challenges. Then these predictions “light up areas” inthe 3D model or list components where you may
want to investigate maintenance or further analysis, creating insights. What glues this together isa set of data products making up the continuously
updated digital twin. But how do you represent
all these variations of structured data elements,and how can you ensure that you can handle thereplacement of a pump without breaking yourmaintenance prediction?

WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →Data models to the rescue
Physical, industrial systems are complex to represent, and there is no single representation thatapplies to all all the different ways you need toconsume the data. In oil and gas, drilling a well isvery different from operating a well, and drilling awell offshore is very different from drilling a wellonshore.

companies have their own adaptations or extensions. Addtionally, they would also benefit fromsharing specific subsets of data with their
suppliers. Reusability of subsets of the data in adata model thus becomes an issue because, forexample, when you refer to a pressure value on a
pump, it may be called different things in different

data models (and languages). Still, you want toaccurately and consistently refer to the samething across all your activities.

Many well bores are drilled for one well, but not all
will be put into production, and once in production, you need operational data, but data gathered as part of drilling may still be relevant. In
manufacturing, understanding how an individual
piece of equipment is performing is very different
from measuring how materials flow through the
production line or process.

©COGNITE 2023 — COGNITE.COM

10

Individually, all pieces of equipment perform withintolerable levels, but the final product quality as theraw materials move through the process may be
off-specification. The complexity tof representing
equipment, assets, and processes is true forrefining and chemical, food and beverage, metals
and mining, and most asset-heavy industries.
The solution to this complexity is standardizing
on a set of data models containing subsets ofthe same data, allowing you to view the data fromdifferent perspectives and then add other additional data depending on your goals. Although
there are industry standard data models, most
WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →Domain data models

WHY COGNITE DATA FUSION® →The data models shown in the diagram below are
members of a bigger domain data model, and acomplete domain data model that represents
all needed data aspects of a physical system isthe data foundation for an industrial digital twin.
Cognite Data Fusion® supports 2D and 3D models
to visualize each digital twin but represents theunderlying data in a meaningful way for you to use

BENEFITS FOR YOUR TEAMS →that data. The shown example is simple but still
illustrates the complexity. But what if you want milliseconds in your start_stop model in your work_orders? All your work orders up to this point will haverecorded only seconds, and all other applications
expect this format. You need to support new usesof start_stop with milliseconds while ensuring that
old uses of the seconds-only model do not break.
The classic approach from the IT world is to upgrade
everything to use milliseconds and migrate the olddata to use 00 milliseconds. In the industrial world,such changes happen continuously, and since
you need your non-IT domain experts to be able tobuild dashboards, solutions, and models, this old
migration model does not work.
▼ Manage versioning with data contextualized
into a domain data model11

A domain data model is built up the way you
would expect: you start with primitive types orproperties like integers, floats, and strings, butalso include references to Cognite Data Fusion®
industrial data types like 3D nodes, time series, orother customer-defined specified types. You can
see this data as classic database tables. However,you can group some properties, like a start date
and a stop date, and reuse this group of properties across your data models. Or you can use thedefinition of a “work order” as a foundational typethat you can reuse in other data models. This reusability is also extended with versioning in such a
way that your data products can be consumed
while also evolving the data models. This protects
you from breaking running dashboards, calculations, and predictions.

The diagram to the right shows this reusability.
Even if you update your contrifugal_pump model toversion 9, the maintenance_predictions model willcontinue to reference version 8. Since inlet_pressure uses pressure - version 1, the maintenance_
predictions model can use pressure - version 1 init’s calculations. You can thus continue to use themaintenance_predictions in your dashboard tomonitor your pump without fearing that it will break.

©COGNITE 2023 — COGNITE.COM

In Cognite Data Fusion®, predefined, configurable domain data models are available for every
customer. These domain data models are bestpractice data models for the industry, so whilean oil & gas customer may want to use the asset
hierarchy (and the CFIHOS standard), a manufacturing customer can follow ISA:95, and a power
and utilities customer can use CIM. Other domain
and purpose-oriented data models (e.g., ISO 14224
Collection and exchange of reliability and maintenance data for equipment) can also be added tothe same project, thus offering a different view ofsome or all of the data.

CONTACT SALES →Consuming data

Cognite Data Fusion® optimizes for the consumption of data. Part of this optimization occurs bystoring the data based on typical consumption
patterns. Further optimization is achieved throughcaching, pre-aggregations and data replication
to ensure that data is structured in a way thatwill allow incredibly performant queries and data
WHY COGNITE DATA FUSION® →A dashboard built by a data scientist or an application that monitors operations and shows
predictions from a running data science model
will likely need data criss-crossing types and data
models (as shown in the maintenance_predictions example). To simplify building and reasoning
around the data for the builder and to allow using
meaningful names on the data for the particular problem to be solved, Cognite Data Fusion®
supports solution data models. Solution data
models offer a mirror into the data specificallytailored to the solution or the application, andcan evolve with new versions of the solution orapplication.
Of course, the domain data models may evolveand be versioned as well, but the solution data
models can evolve on a separate cadence.

BENEFITS FOR YOUR TEAMS →CONTACT SALES →Solution models also allow for the scaled rollout
of applications that are built on top of Cognite
Data Fusion®.
The solution model acts as a stable data interface
for the application, and underlying domain variations across sites and customers can be compensated for by changing the mapping of data into
the solution data model.
This functionality allows Cognite Data Fusion® tosupport scaling of applications and dashboards
across factories and assets with similar problems, but where data is structured and named
differently.

12

Let's say you can find the data using the domain
data models that have the data represented in fullcontext. However, when you have found the data,
you realize your work would be greatly simplified if
you could create your own view – a subset of thelarger data model – creating a simpler structure
where only the relevant data elements are visible.
The maintenance_predictions model from theprevious section is an example of such a view.
Maybe in addition to creating your 0-100 healthprediction, you also want to access the specificvalues that were used to calculate the prediction.
Instead of navigating into the bigger contrifugal_
pump data model to find that data for a specifictimestamp, you can expose the pressure values
directly from your maintenance_predictions data
model.

retrieval. While modern databases have similar
optimizations, industrial data like engineering
diagrams, time series, and 3D models have special
usage patterns that are harder to optimize andusually not supported. Also, although you can
use so-called “materialized views” in a databaseto speed up queries of that data, your typicaldomain expert or a data scientist will not be able
to operate on such a granular database level.
You thus need a system that allows consumption
optimization to happen invisible to the builders
and consumers of the data.

©COGNITE 2023 — COGNITE.COM

As an application developer or data scientist
building a dashboard to visualize data, you needto find the necessary data to analyze and solve
your problem. And to iterate quickly, you must beable to consume data in a manageable way.

Onboarding data

All this means that you need a system to support
onboarding, cleaning, and contextualizing the datain such a way that you can easily and quickly findthe information you are looking for, regardless of its
location or type (unstructured documents, scanned
papers, engineering diagrams, vendor specifications, work orders, or maintenance reports).
WHY COGNITE DATA FUSION® →As a data engineer, you thus build your source data
model to reflect each source systems' data you
want to bring into Cognite Data Fusion®. You do thisby first bringing the data from the source system
into the staging areas. Depending on the data,
you may want to use a NoSQL staging area withno structure, a file storage to store a CSV file, or amore traditional SQL schema-based staging area.
From there, you can explore the data and verify
your source data model, figure out where you haveuniqueness and profile the data.
Once you have a clear view of how you want tobring the source data into the source data models,
you need to look at how to map the source data
model onto your domain data models. Cognite

BENEFITS FOR YOUR TEAMS →CONTACT SALES →Data Fusion® comes with predefined mappingsfor common source systems that can be tweaked
to fit the specific implementation. The below
diagram illustrates this data onboarding process.
(For simplicity, it does not show the contextualization and transformation processes that need to berunning continuously and that are set up as part ofthe data onboarding.)
Very often, there is a gap between the physical world and your digital representations due toincompleteness, physical changes, and errors.
Cognite Data Fusion’s contextualization services
can be used in this process to connect and build
your industrial knowledge graph and allow you to
expand your domain data model using contextualized documents, diagrams, 3D models, andon-boarded data.
Below the process is shown as linear, but in reality,
onboarding, structuring, and consuming industrial
data needs to be an iterative process. Cognite Data
Fusion® thus allows updates and changes to theentire process and through this establish sound
DataOps practices where the experts on data, dataengineers and architects can collaborate with theexperts on interpreting the data, the domain engineers and data scientists.

13

Data you need to solve complex industrial problems come from various source systems. Someare traditional IT systems from large vendors like
SAP, others are operational and local, or even only
accessible locally on the equipment itself. Some
data may have been consolidated into a data
warehouse and may have lost some of its originalcontext. Either way, you cannot assume that thedata is in a state where it can be easily used. If you
have multiple systems with the same type of data,
which one is authoritative? Generally, companies
have come further in consolidating IT data into data
warehouses than what they have achieved for theiroperational data, 3D models, and imagery data thattypically is scattered across operational systems.

The primary tool for capturing as much of the original source context and semantics as possible
is through the use of source data models. If theworld was perfect, you could load your data into
the domain data model(s) directly through a data
pipeline e.g., using OPC-UA that supports source
model semantics. The typical ETL (Extract, Transform, Load) pipeline approach is built around theidea of a start state and an "ideal" end state. Unfortunately, industrial data is messy, and sometimes
you need to look at the raw data to understandwhat might have happened, other times you want
the cleaned data that removes spikes or flattens
out and merges gaps.

©COGNITE 2023 — COGNITE.COM

Up to this point, we have assumed that data isalready loaded into the domain data models, structured and put into context with rich connections
across the data. However, onboarding the data intoa structure that can be understood and consumed
is non-trivial and typically the task of the data engineer.

Source systems
Apps, solutions, use cases etc.

Source data model

Domain data model

Asset hierarchy from SAP – OPC from Kepware

Asset or process centric – Follow standards– BOP/BOM from MES

Solution data model
Data model targeting data consumption for use cases(e.g. OPC, ISA95) – Custom semantic types (CNC)

Optimized data models for applications, data scientists and other

Liberate data in source systems by having them modeled

Domain data models are optimized for reuse between application

solutions. We provide a GraphQL interface with auto generated

and queryable in Cognite Data Fusion® through the samedevelopers, data scientists and solution developers. We offer a

SDKs for minimal code. This provides Backend as a Service (BaaS)

API interfaces.

set of industry standard OOTB data models that can be extended.

to reduce cost of development and maintenance of solutions.

WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →©COGNITE 2023 — COGNITE.COM

14

RAW

Cognite Data Fusion®’s data modeling architecture
Putting it all together, the below diagram illustrates the high-level view of how data originatingfrom existing OT, IT and engineering source
systems are on-boarded into Cognite Data
Fusion® through the use of source data models
that are then stored in the organization’s domain
data models such as CHIFOS or ISA:95.

Cognite Data Fusion® has support for a rich
set of industrial data types, and while the mostcommon domain data model has been the asset

hierarchy, Cognite’s new digital twin modelingcapabilities are expanding the ease and speed
at which new data models are being developed.
If you are interested in learning more about how
Cognite is enabling industrial solution development, news on releases and upcoming changes
can be found on COGNITE HUB!

©COGNITE 2023 — COGNITE.COM

15

These domain data models are the reference
models, or digital twin models, used throughout

the entire organization for data discovery andcommunication. Application developers and data
scientists can build solution data models fortheir specific needs that will make an organizedview of the relevant data from the domain data
model(s).

WHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →Want to know more about our product?

Explore more insights from Cognite

ANALYST REPORT

BLOG

Discover how Cognite Data Fusion®
makes data more accessible andmeaningful, driving insights that
unlock opportunities in real-time,
reduce costs, and improve theintegrity and sustainability of youroperations.

Customer interviews and financial
analysis reveal an ROI of 400% andtotal benefits of $21.56M over three
years for the Cognite Data Fusion®
platform.

Discover our rich catalog of industry insights and technology deep
dives.

WATCH NOW →GO TO STORIES →READ THE REPORT →READ OUR NEWEST BLOGS →©COGNITE 2023 — COGNITE.COM

Learn from Cognite customers andproduct managers how Cognite
Data Fusion® simplifies and streamlines the data experience of a
subject matter expert.

16

CUSTOMER STORIESPRODUCT TOURWHY COGNITE DATA FUSION® →BENEFITS FOR YOUR TEAMS →CONTACT SALES →COGNITE.COM →