Searching:
0 results found
BackGlossary
| Terms | Description |
| Alarm | An alarm is an entity that is generated after a Rule criterion has been met and displayed in the portal. An alarm is triggered by logical conditions applied to the events/readings of devices. Alarms are characterized by their severity (major, minor, critical or warning) and their timestamp. |
| Application | An application is a managed project managed. Each application can be used as a standalone portal for monitoring and controlling your IoT devices, such as Smart Building or Smart Parking. Each application can have a separate login page and its own tailored settings, such as language or custom design. |
| Audit | The Audit feature provides a history of all user driven activities within the Axonize system, with details about the activity itself. |
| Calculated Event/Custom Events | Any event that is generated by the calculation engine and not by data received is a calculated event also referred to as custom event as well. |
| Calculation Engine | The Axonize calculation engine allows you to create new dynamic data streams based on data streams that come in from devices. This can be done either at a device level or by leveraging the group hierarchy to aggregate streams from throughout the hierarchy. To work with the calculation engine you create custom events on either the product or group template. All custom events will output a single data point per execution. In addition, custom events are nestable, so you can create a custom event on top of custom event. |
| Dashboard | A dashboard is an at-a-glance customized view that you can create to enable the monitoring and operation of your devices. You can create multiple dashboards and select and configure the widgets that each contains. |
| Device | Axonize distinguishes real physical devices from virtual devices. Real devices are real-world entities that send measured events/readings. Virtual devices are virtually generated entities that periodically send simulated random values for simulation. A device in Axonize is a representation of a physical entity or sensor in the real world, for example this could be a specific temperature sensor or a field gateway. When viewing the device in Axonize you can see the readings it has sent, the values currently set, and other information about the device. |
| Digital Twin | A representation in Axonize of a specific logical entity, for example this could be “Floor 1”, “North Beach Parking Lot”. A digital twin is an enhanced group, meaning that it has the capabilities of groups in terms of hierarchy, and in addition it has readings, properties and calendars. A group with associated to a group template is considered to be a digital twin. |
| Event/Reading | The definition of an incoming data stream, this includes the type of data, the event name, and display parameters like color ranges and icons. |
| Group | An entity in our hierarchy representation, a group can have one parent group allowing the customers to create hierarchy trees, and devices can be members in multiple groups. So you can have groups that delineate a spatial hierarchy, but also have a hierarchy based on devices types (All devices that are HVACS, and then sub groups based on manufacturers). |
| Group Template | Similar to how the product defines devices, a group template defines the digital twins. A user can define which events and properties the digital twin has. Usually a group template will only have calculated events. |
| Master Application | A master application is the initial application that is created during the onboarding process. The master application can be used as a basis for creating your own tailored application.
The master application cannot be deleted. |
| Parent Device | If a device is connected through a physical gateway, you can define that relationship in Axonize by defining the field gateway the parent device of the sensor. |
| Product | A product is the device manifest for a specific device type. In the product a user can define the events, commands and properties the device has. In addition, the user can define a Self-Service Gateway mapping that applies to these devices. For example, a product can be for the ACME HVAC Unit 5000, which emits a temperature event, has On/Off commands, and has a property for “Target temperature”. All these things can be defined on the product. |
| Reading | A single point on the data stream, a reading will have data to identify to which data streams it belongs as well as date and value |
| Report | Reports enable the creation of detailed and downloadable views about the historic activities and states of tenants, applications, products, devices, alarms or users. |
| Rule | A rule is a condition that invokes an alarm when certain criteria are met. |
| Tenant | A tenant is a single customer instance that serves one customer account. A tenant can create multiple applications and multiple sub-tenants. |
| Thing | Since a lot of the functionality is shared between devices and digital twins, if we wish to indicate that it can be either one, we use the term thing. |
| Type Code | In order to normalize the data as much as possible, we want to understand what kind of data is being received, not only in the physical data type but also what it means. To that end we have the type code, with each data type having its own number (For example, temperature is 7, utilization is 44, etc), later this type code can be used for filtering, aggregation and rules. For the cases where the data being sent is not already defined, Axonize offers generic type codes. For a full list of type codes see separate documentation. |
| Widget | Widgets are available micro services, which can be used on a dashboard. Each widget fulfills a predefined purpose. For example, to show the localization of a device or send a command to a device. |