Types storage

Types are stored within a CONNECT data store and are accessible via the Type Management data service. Type Management provides centralized definition and management of reusable data type definitions across your CONNECT account. It enables you to create standardized schemas that describe business objects—such as physical assets, operational events, and other real-world resources—ensuring data consistency and validation.

Unlike service-specific type systems such as streams types, which are optimized for time-series data storage within that service, Type Management provides common types that can be referenced across multiple services in your account. These common types act as the foundation for maintaining shared data structures, allowing Entity Management and Event Management to share a unified understanding of how to represent and validate your business objects.

Type definitions can range from simple property types to complex structures with inheritance relationships and metadata attributes. The service supports both individual type operations and efficient bulk operations for managing multiple type definitions simultaneously.

Common types

A common type is a reusable data structure definition that is the fundamental resource you work with in Type Management. It describes the structure and validation rules for data used across your CONNECT account. By creating a common type, you create a reusable data model that helps organize, standardize, and interpret data across your account.

Note: Common types are currently available for use with events and entities. Common type support for streams using the Type Management service is planned for a future release. Types for streams are currently managed using the Type endpoints available in the streams service. For more information, refer to Stream types.

Common types help maintain consistency across Entity Management and Event Management. For example, a wind turbine entity might include components with types like Wind Turbine and Equipment, while events might use types like Turbine Alert or Maintenance Event. By managing all these types centrally, you can ensure consistent property definitions and relationships across services, making it easier to correlate data and build integrations as your data model evolves.

Common type elements

A common type consists of several elements that define its structure and behavior. Every common type has a unique ID and name that identifies it within your account. The name helps users understand the type's purpose, while the ID provides a stable reference for programmatic access.

The most important elements of a common type include:

• Properties: Define the data fields that instances of the type can contain, such as numeric values, strings, or dates.

• Relationships: Define how instances of the type can connect to other resources in your account.

• Inheritance: Allows types to derive from base types, inheriting their properties and relationships while adding specialized definitions.

• Classes: Broad categories determined by the root type from which a type ultimately inherits, enabling efficient querying of related resources.

• Lifecycle state: Indicates whether a type is active or deprecated, controlling its availability for new implementations.

Common types also include standard fields such as descriptions, audit information (created/modified dates and users), and system flags. These standard fields are not covered in detail here. For a complete reference of all type fields and attributes, refer to Type Management.

Properties

A property is a value associated with a resource that can be included in a type any number of times. Each property definition describes a single piece of data. Property definitions can provide additional context, such as whether a property is required (via the IsRequired flag), or supply a unit of measure (uom) for a numeric property.

For example, consider a wind farm domain where you define "Wind Turbine" as a common type to describe turbine assets. This type might include property definitions such as average power output, location, and installation date.

Relationships

A relationship is an association between resources, and may also be included in a type any number of times. Each relationship definition models a specific association. Every relationship must declare one or more targetTypeIds that indicate which resource types are valid participants. Relationship definitions can also specify whether a target is required (using the IsRequired flag) and whether it targets a single resource or a collection of resources (using the isCollection flag).

Continuing the wind turbine example, you might define relationship definitions that associate turbines with maintenance documentation or inspection records.

Inheritance

A type may declare a base type, which is a parent type from which properties and relationships are inherited. The inheriting type typically adds new property and relationship definitions beyond those inherited from its base type. This inheritance model allows you to create a hierarchy of types that become increasingly specialized at each level.

For example, BaseAsset serves as the root-level type for all hard assets. A Pump type that inherits from BaseAsset might add a definition for the pump's flow rate. A Centrifugal Pump type could then derive from Pump and introduce an additional property that indicates rotational speed, which would only be applicable to pumps of that specific subtype.

Classes

All non-enumerated common types have an associated type class, a broad category that maps to a root type. Each root-level type, such as BaseAsset or BaseEvent, has a unique classId and className that is inherited by all descendant types. This allows you to easily query the system for all resources that belong to one of these broad categories.

For example, all event resources have a type that is BaseEvent or one of its descendants. BaseEvent is associated with the Event category (classId 3), and so all types in this hierarchy will have a classId of 3 and a className of Event. This classification is inherited automatically through the type hierarchy.

Refer to Root classes and class IDs for more information.

Lifecycle state

The lifecycle state, or simply "state", indicates whether a type is active or deprecated. Marking a type as deprecated signals that it should not be used for new instances while allowing existing references to continue functioning.