# Known Limitations

As an Info Model Developer, we may need to create a relationship between two devices. While creating these relations, we may come across the two scenarios below which can be considered as known limitations on the Ability Platform:

To use Inheritance, the base type needs to be defined first, as it is being inherited by the derived type. Now, suppose we want to add a derived type as a reference on the Base Type. In that case, the derived type needs to be defined first as being used as a reference on the Base Type. This creates a cyclic dependency as derived type creation depends on base type creation, and adding derived type reference on Base Type is dependent on derived type creation.
While instantiating a device type object which has a related configuration type, the related type object will also get instantiated with default or custom values as given by the developer during related configuration type creation. However, there is no option for the developer to override the default values of the related configuration type object when instantiating a device type object in one go.

# Device Relationships

For some systems, it may be necessary to connect or create a relation between two devices.

For the scenario where the relation between two devices who are in same domain (i.e. they have the same models), we need to add the reference device type information to our referencing device type definition.

Using the references tag, the type definition JSON entry will look like this:


  {
  "model": "abb.ability.device",
  "typeId": "device.type.cst.base",
  "version": "1.0.0",
  "properties": {
    "nominalCurrent": {
      "dataType": "integer",
      "value": 10
    }
  },
  "references": {
    "BaseChildRef": {
      "isHierarchical": true,
      "to": [
      {
        "type": " device.type.cst.derived@1"
      }
      ]
    }
  }

To create a relation between two devices in different domains, we first need to add the necessary information to our device type definition.

Using relatedModels tag, the JSON entry in the type definition will look like this:


  {
  "model": "abb.ability.device",
  "typeId": "device.type.cst",
  "version": "1.0.0",
  "properties": {
    "nominalCurrent": {
      "dataType": "integer",
      "value": 10
    }
  },
  "relatedModels": {
    "abb.ability.configuration": {
      "type": "config.type.cst@1"
    }
  }
}

# Inheritance and Cyclic Dependency Between Base and Derived Type

Along with inheritance, if an information model developer wants to add derived type as a reference on a Base Type,

First, we need to create a base type without any child reference in the body
Then, create a derived type with the baseTypes attribute.
Once the derived type is created, only then will we be able to add the derived type as a reference on a Base Type.

This creates a cyclic dependency, as derived type creation depends on Base Type creation, and adding derived type reference on Base Type is dependent on derived type creation.

While creating a base type (say device.type.cst.parent), if we refer derived type (say device.type.cst.child) as reference using the 'references' tag, it will throw an error as “Type definition device.type.cst.child@1 is not defined in registry.":

POST


  {
  "model": "abb.ability.device",
  "typeId": "device.type.cst.base",
  "version": "1.0.0",
  "properties": {
    "nominalCurrent": {
      "dataType": "integer",
      "value": 10
    }
  },
  "references": {
    "BaseChildRef": {
      "isHierarchical": true,
      "to": [
      {
        "type": " device.type.cst.derived@1"
      }
      ]
    }
  }

The reason is, as the derived type is yet not defined, so giving exception while referring derived as a reference on base type definition.

Now as derived type inherits base type, so we have to create initial version of base type without any references like below:

POST

{
 "model": "abb.ability.device",
  "typeId": "device.type.cst.base",
  "version": "1.0.0",
  "properties": {
    "nominalCurrent": {
      "dataType": "integer",
      "value": 10
    }
  }
 }

Once Base type is created, now we will proceed with the creation of derived type which is inheriting base type using 'baseTypes' tags:

POST

{
 "model": "abb.ability.device",
 "typeId": "device.type.cst.derived",
 "version": "1.0.0",
 "baseTypes":["device.type.cst.base@1.0.0"],
 "properties": {
  "Current": {
   "dataType": "integer",
   "value": 20
   }
  }
 }

Now we want to create the reference of the child type in parent type definition,

so we must update the existing parent type definition with a new version to include the references tag and preserve older versions as separate types.

POST

{
"model": "abb.ability.device",
"typeId": "device.type.cst.base",
"version": "2.0.0",
"properties": {
"nominalCurrent": {
  "dataType": "integer",
  "value": 10
  }
},
 "references": {
  "BaseChildRef": {
    "isHierarchical": true,
      "to": [
      {
      "type": "device.type.cst.derived@1"
      }
    ]
   }
  }  
 }

Note that whereas in previous platform releases the Object Model PUT (update) was followed by the (re)creation of missed Related Models, in the present release neither Related Models nor References are altered by the Object Model update operation. This effectively makes Object Model update an "atomic" operation, that is it involves one and only one Object Model. Note that the Object Model POST (create) function remains the same as before.

When defining the relation between two real entities which are under different domains, they are connected using the relatedModels tag.

# Use Case

{
"model": "abb.ability.device",
"typeId": "device.type.cst",
"version": "1.0.0",
"properties": {
"nominalCurrent": {
  "dataType": "integer",
  "value": 10
  }
},
 "relatedModels": {
   "abb.ability.configuration": {
     "type": "config.type.cst@1"
   }
  }
 }
}

When creating a real object for device.type.cst, it automatically creates a related object for configuration type, that is “config.type.cst”.

They both will have the same object Id as they are related models.

The limitation here is that it doesn’t give any option to modify any properties or attributes of the related configuration type object while instantiating it with a device type object.

CONFIG OBJECT MODEL POST

{
"model": "abb.ability.configuration",
"typeId": "config.type.cst",
"version": "1.0.0",
 "properties": {
   "name": {
   "dataType": "string",
   "value": "ABB"
  }
 }
}

DEVICE OBJECT MODEL POST

{
"model": "abb.ability.device",
"typeId": "device.type.cst",
"version": "1.0.0",
"properties": {
  "nominalCurrent": {
  "dataType": "integer",
  "value": 10
  }
},
"relatedModels": {
 "abb.ability.configuration": {
   "type": "config.type.cst@1"
   }
  }
 }
}

If we search for Objects in the Information Model API with the same object Id, but model abb.ability.configuration, the output will give us a config.type.cst Object with default values:

GET

{
"objectId": "68e63988-285c-4d07-91bc-cfb3d8084f0f",
"model": "abb.ability.configuration",
"type": "config.type.cst@1",
"version": 1,
"lastModified": "2019-09-03T05:25:55.066Z",
"properties": {
  "name": {
  "value": "ABB"
  }
 }
}

# Updating objects with different values for predefined properties

To Update the values, we need to pass them along with the Object ID and Model in the Information Model API Object Patch section.

PATCH

{
"properties": {
 "name": {
   "value": "ABBOAA"
  }
 }
}

For the output, when we search again for Objects in the Information Model API with the above filter condition, we will get the following payload with updated values and version 2:

OBJECT MODEL GET

{
"objectId": "68e63988-285c-4d07-91bc-cfb3d8084f0f",
"model": "abb.ability.configuration",
"type": "config.type.cst@1",
"version": 2,
"lastModified": "2019-09-03T05:25:55.066Z",
"properties": {
 "name": {
  "value": "ABBOAA"
  }
 }
}

# Bad Request on variable subscription for long requests that do not include objectIds

When creating a subscription with a user token, filters that do not contain an objectId may result in an error preventing the subscription from being created. The likely HTTP response code may be 4xx. This is due to a service bus filter limitation which only allows for up to 1024 characters. This issue is often observed with a large header that cannot be broken down into small enough filters for the service bus.

To work around this problem, include an objectId in the filter property for the Data Access request. Up to 40 objectIds can be included in the filter. Background tokens do not have tenancy therefore the authorization service does not optimize the ability-condition based on the given objectId in the filter.

# TSI sorting support limitation

When making requests to Data endpoints (variables, events, alarms), be aware that TSI supports sorting properties only by timestamp. Therefore, we do not recommend using the Order By and Limit keywords together on any property other than timestamp.

For example, queries written in a similar fashion to the sample below have a high probability of returning incorrect results:

{
  "filter": "objectId='ee69788f-d8dc-42af-832f-343b1875873c'",
  "date": {
    "from": "2021-06-22T06:33:34.762Z"
  },
  "limit": 2,
  "orderBy": {
    "order": "asc",
    "property": "value.alarmCode"
  },
  "select": {
    "properties": "objectId, model, timestamp, value.limit, value.alarmCode, alarm"
  }
}

← Types Versioning in Object Model Endpoints Object Model Validation Rules →

# Known Limitations

# Device Relationships

# ​​​Inheritance and Cyclic Dependency Between Base and Derived Type

# Inability to override the default values of the configurable type with related model construct

# Use Case

# Updating objects with different values for predefined properties

# Bad Request on variable subscription for long requests that do not include objectIds

# TSI sorting support limitation

# Inheritance and Cyclic Dependency Between Base and Derived Type