Skip to main content

An Introduction to the Twin Engine

The Twin Engine in the Hark Platform allows users to model their assets, create Automations, manage Alarms and more. Below, we'll cover some of the core concepts in the Twin Engine.


Models allow you to model your assets in the Hark Platform and can be created arbitrarily, they can model an Asset, a Location or anything you'd like. They can be have a set of properties on them to denote the data that makes up your Model. Models can have Automations, Events and Alarms linked to them.

When creating a model, it'll require a name, a unique ID and you can give it an icon to represent what it is modelling.


Properties belong on a Model to denote the data that makes up your Model. Properties are arbitrary and can be informational or used to track the current state of an Asset. For example you could add a property for a Location, or a temperature reading from a device.

Property IDs are unique to the Model the property is on, and will be referenced in Ingresses, Automations and other aspects of the Twin Engine.


A Connector in the Twin Engine provides access for other parts of the Twin Engine, such as Automations and Ingresses, to connect to external services for read or write capability. For example, you can create an MQTT Connector to receive data from an MQTT Broker, or send MQTT messages for write capability.


An Ingress is used in the Twin Engine to ingress messages to Models or Events. When a message is received, you can use them to map the incomming data to Model Properties, or emit Events within the Twin Engine. These updates can be used to trigger Automations later.


Automations allow you to do a wide range of actions within the Hark Platform, and they allow you to model your business processes. With a wide range of Triggers, Conditions and Actions you can construct rules to do many things such as manage your data within the Hark Platform, contact external services, active Alarms and much more.

Automations can optionally belong to a Model for organization, but can also exist Organization-wide.

  • Triggers - Defined against an Automation to trigger your Automation when certain actions have occured, e.g: MQTT message, Alarm activated, and more.
  • Conditions - What conditions must pass for your Automation to be triggered? e.g: Time of Day, telemetry and property checks, and more.
  • Actions - Define what to do when your Automation is triggered and passes any Conditions, e.g: Send an SMS or Email, Set a Model Property, Send an MQTT message and more.
    • Each Action can contain an optional set of Conditions against them to only run them when the defined Conditions pass.


Alarms can be activate to help monitor faults or issues with the assets your are Modelling the Hark Platform. For example, when a fault is active on a remote device, you can activate an Alarm, or when telemetry tells you an issue could occur, you can activate an Alarm.

Alarms can be activated, updated or cleared by using our Automations to define the rules for when an Alarm should be activated, updated or cleared.


Events can be raised to track when things have occured, they can be used in many different ways in the Hark Platform such as logging that something has occured, tracking information over time or to trigger Automations. Ingresses and Automations can raise events depending on incomming messages from a Connector, or a set of defined rules on an Automation.