# Data Model

The Best Day application only works if the underlying data is structured in a defined way. This page documents the data model requirements for Best Day to function.

# External IDs

All resources must have external IDs (opens new window) defined. Without external IDs (opens new window), the application will not function.

# Root Assets

The navigation begins at the root asset level. This will represent the top-most navigation grouping in the application. Typically this will refer to a country or production region.

# Production Systems

A production system is the second level of the hierarchy. These must be connected to the root asset with relationships (opens new window). These relationships (opens new window) must be a belongsTo relationship, with the source being the production system and the target being the root asset. Additionally, a production system must have a metadata field called Network Level with the value Production System.

# Production Subsystems

A production subsystem is the middle level of the hierarchy. There may be multiple levels of production subsystems. These must be connected tot he production system with relationships (opens new window). These relationships (opens new window) must be a belongsTo relationship, with the source being the production subsystem and the target being the production system. To create nested hierarchy, the target may also be another production subsystem. Each production subsystem must have a metadata field called Network Level with the value Production Subsystem.

# Wells

A well is the leaf of the navigation hierarchy. This must be connected to the production subsystem with relationships (opens new window). These relationships (opens new window) must be a belongsTo relationship, with the source being the well and the target being a production subsystem.

# Time series

Every time series must:

# External ID format

Each time series' external ID must have the following format:

<ASSET_EXTERNAL_ID>_<NETWORK_LEVEL>_<PRODUCT_TYPE>_<VALUE_TYPE>
1

Specifically:

  • <ASSET_EXTERNAL_ID> is the external ID (opens new window) of the parent asset.
  • <NETWORK_LEVEL> is one of:
    • Production System
    • Production Subsystem
    • Well
  • <PRODUCT_TYPE> is the type of product (eg: CO2, Oil, Water, etc)
  • <VALUE_TYPE> is used to indicate whether a timeseries represents production or IPSC values.
    • PRODUCTION: this timeseries represents how much has been produced for the asset to that point in time.
    • IPSC: this timeseries represents the IPSC value for systems and subsystems.
    • BEST_DAY_PREDICTION: this time series represents the prediction of the best possible result for that point in time.
    • TOTAL_CAPACITY: this time series represents the sum of the produced product and any deferments from that point in time.
    • DEFERMENTS_ACTUAL: this time series represents the realized deferments from that point in time.
    • DEFERMENTS_FUTURE: this time series represents the future (theoretical) deferments which overlap that point in time.

# Deferments

Deferments must be recorded in CDF as events. These events must have external IDs (opens new window) specified. The deferment events must be linked to their respective assets using the assetIds field available to events.

# Deviations

Deviations must be recorded in CDF as events.

The following assumptions are made about the events. If these assumptions do not match the data in CDF, then the behavior of the app will be unpredictable.

# Required fields

If these fields do not conform to their defined specifications (presence or format) then they may be omitted from the application.

  • type field must be set to production_deviation.
  • externalId field must be set to a unique value.
  • assetIds field must contain the relevant asset ID(s) for the deviation.
  • startTime field marks when the deviation is starting.
  • metadata field contains a key-value representation of data.
    • PRODUCT represents the product with the deviation (eg: "Oil", "Gas", etc.) If this field is omitted, then the deviation will not be used by the application. This does not need to be human-readable as translation capabilities are possible. However, this will be used as a fallback should translations be missing.
    • ESTIMATED_VOLUME represents the estimated volume of the deviation for the associated PRODUCT. Note that this value is unit-less. If this field is omitted or is non-numeric, then the deviation will not be used by the application.
    • ESTIMATED_VOLUME_UNITS represents the units used for the ESTIMATED_VOLUME field. If this field is omitted, then the deviation will not be used by the application.

# Optional fields

  • endTime field marks when the deviation has ended. If this field is not set, then the deviation will be treated as ongoing.
  • metadata field contains a key-value representation of data.
    • DETECTED_DATE field marks the timestamp of when this deviation was first detected. If missing, then the startTime is assumed to be the time when this deviation was first detected. This should be an ISO 8601 (opens new window) date format.
    • IGNORED_DATE field marks the timestamp of when/if this deviation was last ignored. If missing, then the deviation was never ignored. If ignored again at a later date, then this field will be replaced with the new timestamp. This should be an ISO 8601 (opens new window) date format.
    • RESOLVED_DATE field marks the timestamp of when/if this deviation was last resolved. If missing, then the deviation was never resolved. If resolved again at a later date, then this field will be replaced with the new timestamp. This should be an ISO 8601 (opens new window) date format.
Last Updated: 2/10/2021, 4:24:42 PM