Glossary

Term Description

Term	Description
Asset	A piece of hardware. Assets can be part of the customer’s business (e.g. a wind turbine) or SMC-installed, like a Raspberry Pi or a custom-built connector.
Service	A nodejs, python or 3rd party microservice which performs a function, without representing a specific asset.
Platform	The collection of software functionalities that define and provide the communication layers and services through which an SMC microgrid can be monitored and controlled. This does not include software or hardware that exists solely to communicate with a specific asset.
Agent	A software process adhering to SMC conventions which runs, proxies, or represents an Asset or service. There are currently both Python and NodeJS agents - and they don’t behave quite the same!
SMC Node	A compute device running an `Agent`. This may be an actual Asset like a Raspberry Pi or it may be a virtual node in the cloud.
Signal	A stream of measurements, described by persistent properties.
Device	A catch-all term to represents some notion of an entity with signals. A device may be an asset (e.g. a Wind Turbine), a part of an Asset (e.g. a Wind Turbine Generator), an SMC Node (e.g. a Raspberry Pi), or even a software process so that resource usage and service metrics can be tracked. Devices may also be 'virtual'; in that they are masquerading as some kind of Asset, but are in reality pure software constructs.
Edge	Devices and Services which typically deploy onsite. Virtual devices may be deployed to the cloud for convenience, but they are still in principle part of the Edge world.
Infra	A data- and customer-siloing approach. Initially an infra was a method of differentiating between deploys to separate physical installations, with an entire SMC Stack provisioned for it. This later expanded to allow a given user to access multiple infras. Alongside a move towards a multi-tenant architectue, this led to infras also becoming a mechanism for data-siloing. The intention now is to move away from the current infras approach, and towards a more multi-tenanted approach.
Broker	An MQTT Broker. These typically have a one-to-one relationship with Infras at the moment. All devices for an Infra ultimately communicate over one central broker, although for network robustness there may be local brokers that bridge co-located SMC Nodes or multiple processes on just one Node.
UI Deployment	A collection of user-facing services deployed to AWS. These sit outside the infra concept, but talk to them.

Asset

A piece of hardware. Assets can be part of the customer’s business (e.g. a wind turbine) or SMC-installed, like a Raspberry Pi or a custom-built connector.

Service

A nodejs, python or 3rd party microservice which performs a function, without representing a specific asset.

Platform

The collection of software functionalities that define and provide the communication layers and services through which an SMC microgrid can be monitored and controlled.

This does not include software or hardware that exists solely to communicate with a specific asset.

Agent

A software process adhering to SMC conventions which runs, proxies, or represents an Asset or service.

There are currently both Python and NodeJS agents - and they don’t behave quite the same!

SMC Node

A compute device running an Agent. This may be an actual Asset like a Raspberry Pi or it may be a virtual node in the cloud.

Signal

A stream of measurements, described by persistent properties.

Device

A catch-all term to represents some notion of an entity with signals.

A device may be an asset (e.g. a Wind Turbine), a part of an Asset (e.g. a Wind Turbine Generator), an SMC Node (e.g. a Raspberry Pi), or even a software process so that resource usage and service metrics can be tracked.

Devices may also be 'virtual'; in that they are masquerading as some kind of Asset, but are in reality pure software constructs.

Edge

Devices and Services which typically deploy onsite.

Virtual devices may be deployed to the cloud for convenience, but they are still in principle part of the Edge world.

Infra

A data- and customer-siloing approach.

Initially an infra was a method of differentiating between deploys to separate physical installations, with an entire SMC Stack provisioned for it. This later expanded to allow a given user to access multiple infras. Alongside a move towards a multi-tenant architectue, this led to infras also becoming a mechanism for data-siloing.

The intention now is to move away from the current infras approach, and towards a more multi-tenanted approach.

Broker

An MQTT Broker. These typically have a one-to-one relationship with Infras at the moment.

All devices for an Infra ultimately communicate over one central broker, although for network robustness there may be local brokers that bridge co-located SMC Nodes or multiple processes on just one Node.

UI Deployment

A collection of user-facing services deployed to AWS. These sit outside the infra concept, but talk to them.