The sizing of the overall XMPro system is determined by the following considerations:

• The number of data streams
• How frequently the streams process data
• The size of the data payload
• The number of recommendations to be monitored
• The number of apps and event boards (the number of elements and integration points)
• The number of concurrent users accessing the apps and event boards

Guidelines for sizing the system are provided in this section.

Over time, companies may have to consider scaling the system due to changes in system workload profile, future growth plans, and company policies and procedures. Scaling techniques are described in this section.

An XMPro system consists of five different component types:

• Subscription Manager
• Application Designer
• Data Stream Designer
• SQL Database Server
• Stream Host Servers

While there are many different deployment models possible for the above components (consolidated, distributed, hybrid), the guidance provided in the following table assumes that each XMPro component is installed on its own bare-metal server or virtual machine, in line with the vendor’s recommendations.

Guidelines in terms of CPU, RAM, and storage are provided for small, medium, and large systems.

The sizing guidelines presented in the previous table have been validated against the system sizes (small, medium, large) as detailed in the following table.

As an example, the table details that a medium system is defined as one where up to 210 Data Streams run across 15 Stream Hosts (14 data streams per stream host) while serving data and triggering recommendations for 10 Applications.

Always start small. Digital transformation is achieved by many small projects that lock in success at each step. The overall goal is to achieve project success early and expand.

Over time, end users typically decide to deploy an increasing number of manufacturing use cases to run on XMPro. The system needs to be scaled accordingly to manage growth.

In order to understand how to scale XMPro, it is first useful to understand how workload is distributed across the XMPro system, as described the following table.

There are two main types of scaling within XMPro:

• Stream Host scaling
• Platform Server resource scaling

As more digital twin use cases are developed, new Stream Host Machines need to be deployed to run the associated use case Data Streams. A typical XMPro installation has multiple Stream Host instances connected to one Platform Server instance, as shown in the following figure.

Assuming the Platform Servers have sufficient resources (CPU, RAM, and storage) to meet the workload, the system can be easily scaled by just adding additional Stream Hosts.

For information of how to install a new Stream Host, see Install Stream Host.

The preferred approach is to have a separate infrastructure for the stream host.

It is possible that your XMPro deployment has only one Stream Host. However, this is rarely the case, and we suggest the following considerations:

• Consider each location having a dedicated Stream Host.
• A critical Data Stream, like pressure readings on a pressure vessel, may have its own dedicated Stream Host.
• If a payload for a Data Stream is large and frequent, then consider a dedicated Stream Host for that Data Stream.
• Having several Stream Hosts can improve the resilience of your system.
• Network latency and geographical spread could be factors in considering the case for multiple Stream Hosts.

Over time, as additional Applications, Recommendations, and Data Streams are added to XMPro, the resource utilization increases as expected on the Platform Servers. End users should reference the tables in this section to ensure that the appropriate CPU, RAM, and storage continues to be allocated to the individual Platform Servers.

Deployment of the XMPro Platform Servers on VMware comes with the significant benefit that, if your load or performance requirements change in the future, CPU, storage, and memory configuration changes can easily be made in the VM’s settings. Some of these changes can be made on-the-fly with no production downtime.