Platform Specifications

Below you can find a list of Platform specifications and capacity. Remember to always check the Release Notes for the Known Bugs related to the particular release.

This page contains information regarding the latest version of the Platform Cloud only and other Platform components compatible with the latest version. You can find the full compatibility tables in the Release Notes Pages.

Each component's section is divided into two Tabs:

• Specifications: provides the maximum capability or a limit. This may be due to a defect, limiting rule, or other restrictions.
• Scaling and Performance: provides insight into parameters that the Operations Team may modify to provide additional capabilities and incur additional costs.

Cloud Global

Weak ciphers cannot be disabled

It is currently impossible to disable the following ciphers because AKAMAI and Microsoft do not provide such possibility:

• ECDHE_RSA_WITH_AES_128_CBC_SHA
• ECDHE_RSA_WITH_AES_256_CBC_SHA

Content Under Development

Admin Portal

Max 5000 users can be selected for batch operations: For performance reasons (which depend on the computer specification and amount of available memory), currently the user interface allows the selection of up to 5000 users for performing batch operations (e.g. deleting, managing their grants).

Content Under Development

Cloud Region & Instance

Principal Manager

Parameter	Value	Comments
AAD group	200	Max number of AAD Users groups
Tenant	495	To change up to 995, requires Microsoft ticket
Solution	1000	Max number of items to fetch per single Http GET call
Contract
Application
User
Grant
Group
Device
Role
RBAC Resource
RBAC Permission
RBAC Operation
Identity Provider – X.509
Identity Provider - OIDC
DPP process	500	Max number of processes per minute
Platform Instance	1	Max instances per Ability Region
DPS root certificate	25	Max number of certificates per Platform
Number of devices per solution	40000	The limitation is caused by a max 2MB document size in CosmosDb. There is no workaround to this except to create a duplicate solution to add additional devices beyond 40K devices.
APIM/AuthZ Principal/OM mappings update frequency	10 minutes	Mappings between Principal and Object Models (authorized for Principal) are cached and refreshed after the timeout period. Effective authorization rules (after RBAC changes) will be in place after up to 10min.
QEL limitations	Expression "name in ['x']" doesn't work due to bug in MongoAPI	Expression "name = 'x' OR "name = 'y' " should be used as a workaround. MongoAPI limitation
Access Token requisition limitations	When concurrent requests to get a bearer token are sent, a client can receive a Bad Request response	The recommendation from Microsoft is the application must wait for a few seconds before trying to get the token for the application that has been created. According to Microsoft, it takes a maximum of 60 seconds to replicate the Application Settings across Azure regions.
B2C calling limitations	Application name cannot contain the '&' character	Graph Endpoint fails when ampersand is present in displayName in the body
Bug with assigning a role to Service Principal (application)	It's suggested to put 5 minutes delay between app creation and role assigning	The service principal is created in one region; however, the role assignment might occur in a different region that hasn't replicated the service principal yet. It's a limitation from Microsoft's side

Content Under Development

Instance API

This section covers TDR (Type Definition Registry), IM (Information Model), Audit, DCS and Data Access.

Audit API

Parameter	Value	Comments
Audit Log Event size	32KB	Audit Logging works based on platform events. In some circumstances (ie. user having access to many objectIds), a produced platform event may be large. When the size of such platform event exceeds 32kb, the audit logging "data" parameter stores only an information in form of JSON entry: { "auditLogInformation": "Event body too long" }
Misleading Log Response	When creating a group, the AuditLog incorrectly displays Group.Updated instead of Group.Created.	This is a limitation caused by existing ChangeFeed Azure Service behavior. The ChangeFeed returns only the latest state of a particular document, not its entire history of all the updates.

DataAccess API

Parameter	Value	Comments
TSI Gen1 - limit of properties	S1 SKU - 600 properties (columns), S2 SKU - 800 properties (columns), P1 SKU - 1000 properties (columns)
TSI Gen1 - limit of concurrent queries	S1, S2 SKU - 10 concurrent queries, P1 SKU - 30 concurrent queries	DataAccess API must be scaled to 3 instances to use all 30 channels supported by P1 SKU
TSI Gen1 - max event size	S1, S2, P1 SKU - 32KB	Events, Alarms and Telemetry + overhead cannot exceed 32KB. Packets larger than 32KB are truncated
TSI Gen1 - query grouping limitations	Queries grouping can be done only on columns that are denoted with the data type.	Since the "value" column can be any simple data type (string, double, Boolean, timestamp) or complex object, the system cannot determine at query time what to group by for data type. By default, the grouping operation data type is assumed to be "string".
The DPP may generate additional values for Hot Path, Warm Path, and Cold Path storages, which provides to storing excessive duplicate values.		The user applications must ensure that they apply a filter prior to processing the data in the application. There is no workaround when aggregates are processed. For example, if aggregates count, sum or avg are used the duplicate values will be included in the results.
TSI Gen1 stores DateTimes in ISO 8601 UTC format only. This is in opposite to Hot Path and Last Known Value, which store DateTimes as it comes.		If you want to have all dates in Hot/Last/Cold/TSI stored in the same format, insert some text before or after the date. Examples: "Time: 2021-05-12 21:46:46.8866929" "2021-05-12 21:46:46.8866929 CET"
Last Known Value can only be filtered by properties: model, objectId, alarm and alarmKey.		If you need to filter by other fields, use TSI query (all queries which don't contain "select":"last")
The DataAccess API will return a 408 Request Timeout HTTP status code if no response is returned from TSI in the specified time limit.		To configure the time limit you want, you need to add the "TimeSeriesConfiguration: MaxDependencyRequestTimeoutInMilliseconds" key into the Configuration tab in the AbiDaSvcAs* app service.

Model & Object API

Parameter	Value	Comments
OM - limit of properties and variables with a short value	9000 - max number of properties and variables with a short value in a single model
OM - limit of complex properties and variables	3000 - max number of complex properties and variables in a single model
OM - limit of payload size	64KB - max document size uploaded/downloaded	IoT Hub limitation. A too large Object Model returns 400 (BadRequest) with a detailed error message. The max payload size will be increased in a future update. Click here for more information.

Storage API

Parameter	Value	Comments
APIM - max supported throughput	7MB/sec - maximum throughput of file uploading process	Affects APIM Instance Scaling
APIM - max size of files uploaded	250MB - global storage 250MB - object storage	Affects APIM Region Scaling

Recommendations:

The data processing pipeline may generate additional values for hot path, warm path, and cold path storage. The values can be recognized by an identical timestamp. This behavior may have existed in prior versions, but is more likely seen in the current version with the enhancements in the processing pipeline (new validation and data quality decoration functionality, revamped hosting, infrastructure). The user applications must ensure that they apply a filter prior to processing the data in the application. There is no workaround when aggregates are processed.

For example, if the aggregates count, sum or avg are used, duplicate values will be included in the results.

Taking the TSI limitation of 10 concurrent requests (S1, S2 SKU) into account, we recommend you implement a queue mechanism to spread your queries to Data Access API over time. 10 concurrent queries does not mean 10 queries per second.

For example:

• if your query takes 1 second - you may have 10 queries per second,
• if 500ms - 20 queries per second,
• if 100ms - 100 queries per second,
• if 5 seconds - only 2 queries per second, etc.

For queries containing "last known value", be sure to provide all the following information whenever possible:

• model,
• objectId,
• variable/property name.

These are parts of the Redis cache key. If you don't provide any of these values or use "starts_with"/"ends_with" predicates, Redis performs a full scan. Depending on the cache size, this may take a significant amount of time, and can cause a timeout response after 15 seconds, or the whole operation might execute very slowly and could even take a few minutes. Querying across several models, ObjectIds, etc. is perfectly fine, and is recommended. Redis queries complete very quickly when all the key components are provided.

Keep In Mind

If your query requests both Redis and TSI, the slowest component impacts the total response time.

Data in Last Known Value queries can be filtered by:

• Model, ObjectId, Alarm (name), and AlarmKey for alarms
• Model, ObjectId and Event (name), for events
• Model, ObjectId and Variable (name), for variables

This has an implication on LKV performance. The more unique combinations of model-objectId-alarm-alarmKey, model-objectId-event and model-objectId-value altogether, the lower the performance of LKV queries. Keep this in mind when designing your system, and ensure you keep a reasonable number of unique alarmKeys values.

Check out our Known Limitations page for more information.

Otherwise, see this TSI Gen1 limits page which also includes limitations mentioned in the Specifications tab.

Data Ingestion

Data Size

Content Under Development

Data Bandwidth

Ability Platform Data ingress is limited by the TSI SKU selected. Three tiers of TSI Gen1 are available: S1, S2 and P1.
Each tier has different bandwidth specifications.

Parameter	Value	Comments
TSI Gen1 - max bandwidth	S1 SKU - 120KB/s	1KB or less data 120/s, 1-2KB data maximum is 60/s, 32KB data 3.75/s
	S2 SKU - 1200KB/s	1KB or less data 1200/s, 1-2KB data maximum is 600/s, 32KB data 37.5/s
	P1 SKU (Hot Path enabled) - 1MB/s	6000/s of 200 byte telemetry, 3000/s of 400 byte telemetry, etc.
	P1 SKU (Hot Path disabled) - 6MB/s	32000/s of 200 byte telemetry, 16000/s of 400 byte telemetry, etc.

Data Storage and Duration

TSI can support up to 400 days of data if the configured data storage can hold 400 days of data.
Max storage capacity is based on the number of events or bytes stored, whichever comes first.

Parameter	Value	Comments
TSI Gen1 - max data storage	S1 SKU - 30-300GB	1 to 10 UNITs at 30GB each
	S2 SKU - 300-3000GB	1 to 10 UNITs at 300GB each
	P1 SKU - 2700-30000GB	9 to 100 UNITs at 300GB each
TSI Gen1 - max events count	S1 SKU - 30-300 million	1 to 10 UNITs at 30 million each
	S2 SKU - 300-3000 million	1 to 10 UNITs at 300 million each
	P1 SKU - (total storage)/event size

Other Ingress and Data Retention

Parameter	Value	Comments
Azure IOT Hub Ingress	Supports all supported TSI configurations
Data Processing Pipeline (DPP)	Supports all supported TSI configurations	DPP Scales automatically as ingress increases
Hot Path Maximum Ingress	1MB/s	Above 1MB/s data processing cannot keep up
Hot Path Maximum Duration	1 Minute	Data is maintained for 1 minute before being deleted
Last Value Maximum Ingress	Supports all supported TSI configurations
Cold Storage Maximum Ingress	Supports all supported TSI configurations
Cold Storage Maximum Duration	Limits of Azure Storage account
File Storage Maximum Ingress	Limits of Azure Storage account	Customer application is responsible for cleanup
	3MB/s	Uses APIM capacity
TSI Gen1 supported data types	Bool, DateTime/Timestamp, Double, String	TSI does not distinguish between Integer and Double data types

Several components will scale automatically to handle changing ingress rates:

DPP: AKS cluster will add nodes to support additional pods. AKS is configured to add more pods and more nodes when ingestion increases. When ingestion decreases, additional pods are stopped, and if the resource requirements allow, the number of nodes will be decreased.

The default configuration is designed to handle most loading. However, for best stability, you should define the minimum replicas for the DPP consumer as follows:

DPP = @{
  EventHubConsumer = @{
    Replicas = @{
      Min = 8
      Max = 32
    }
  }
}

Cold storage is supported by an app service plan. The Service plan will scale to handle the ingress. Instance will constantly be adjusted to to handle the incoming ingress.

Hot Path: Service bus supports hot path and other Instance functions and must be scaled to support the designed ingress. Service bus supports auto-scaling, but a fixed scale that can handle expected ingress will provide the best performance.

Redis-Cache: The default redis-cache is sufficient for supported ingress at this time. However, in some situations a higher SKU may be required to maintain retrieval performance.

Devices

All IOT devices must communicate with the Cloud. A variety of operations trigger Cloud to Device C2D messages and Devices can trigger Device to Cloud D2C messages. To insure timely delivery of messages between the Ability Cloud and IOT Devices, it is necessary to determine the frequency of D2C and C2D messages, what triggers then, and how the throttling is handled.

IOT Hub

Three tiers of Azure IOT hub are available, S1, S2 and S3. Each Tier supports different levels of C2D message throughput based on tier and the number of units.

Parameter	Value	Comments
IOT Hub S1 C2D	100/min * #units	10 Units of S1 cost the same as 1 Unit of S2
IOT Hub S2 C2D	100/min * #units	10 Units of S1 cost the same as 1 Unit of S3
IOT Hub S3 C2D	5000/min * #units

D2C messages are counted with Telemetry messages. Telemetry message is counted in 4K blocks. A 1 byte message counts the same as a 4K message. A 4097 byte message counts as 2 IOT messages. Where applicable, it is recommended to group messages together at the device to send fewer large messages instead of many smaller messages.

Parameter	Value	Comments
IOT Hub S1 Telemetry/D2C	400,000/day * #units	10 Units of S1 cost the same as 1 Unit of S2
IOT Hub S2 Telemetry/D2C	6,000,000/day * #units	10 Units of S1 cost the same as 1 Unit of S3
IOT Hub S3 Telemetry/D2C	300,000,000/day * #units

Content Under Development

DCD (Directly Connected Devices)

Content Under Development

Content Under Development

Edge

Content Under Development

• Tested on Ubuntu
• Supports ARMHF and X64 out of the box

Content Under Development

• Depends on Hardware
• Depends on Network connections to cloud