Introduction

Production facilities rely on an MES to control and optimize their operations. An MES provides real-time monitoring and traceability of production processes, helping managers make data-driven decisions. It bridges the gap between enterprise systems, such as Enterprise Resource Planning (ERP) and Product Lifecycle Management (PLM), and shop floor operations. Manufacturers need cloud technologies to provide enhanced flexibility and scalability, build resilience, and reduce costs for these critical production systems. Deploying an MES on the AWS Cloud can deliver these benefits along with enhanced security, automated data protection, and increased efficiency.

While a cloud deployment works for many customers, some scenarios require on-premises deployments. Manufacturers might need low latency equipment connectivity, or have specific data residency requirements. In these cases, the manufacturers can deploy the MES locally on premises through Outposts. This article presents architectures for running Siemens Opcenter Execution in the AWS Cloud and on Outposts.

Deploying Siemens Opcenter Execution requires different strategies depending on the environment type, such as development, test, or production, and the modules that you must install. This article focuses on production environments for Opcenter Execution Foundation Discrete or Process (OC EX FN/DS/PR), Opcenter Connect Manufacturing Operations Management (OC CN MOM), and Opcenter Execution Foundation Overall Equipment Efficiency (OC EX FN OEE).

Opcenter Execution in an AWS Region

The following figure illustrates the architecture for a production deployment that’s distributed across multiple Availability Zones.

You can see the customer’s own site on the left, and the AWS Cloud on the right. At the core of the solution, OP EX FN/DS/PR is deployed across three AWS Availability Zones on Amazon Elastic Compute Cloud (EC2) instances. This provides resilience to the loss of one or two Availability Zones. You can add further instances for scalability as needed.

The OC CN MOM application runs on separate Amazon EC2 instances and is distributed across three Availability Zones. This application manages data exchange with other systems that can include on-premises ERP instances or shop floor OPC-UA servers and devices. For file storage, OC CN MOM can use Amazon Elastic Block Store (Amazon EBS) volumes or Amazon Simple Storage Service (Amazon S3). The optional non-critical OC EX FN OEE runs on a single, separate EC2 instance. Amazon EC2 Auto Scaling groups and launch templates automate the deployment of the servers and replacement of EC2 instances if there’s a failure.

The Opcenter application servers run on Windows Server, and Amazon EBS volumes provide storage for all EC2 instances. Opcenter requires a license server accessible to all application servers that can be deployed on a dedicated EC2 instance or alongside OC CN MOM, as shown in the preceding figure. The license server is running in three Availability Zones for high availability.

NAT gateways positioned in public subnets across the Availability Zones provide internet connectivity for the servers. Security groups restrict inbound and outbound server connections at the instance level. At the subnet level, network access control lists (ACLs) provide additional network security controls.

The Opcenter servers can join a Microsoft Active Directory domain, and Opcenter can integrate with Active Directory for user authentication. AWS Directory Service for Microsoft Active Directory, or Microsoft Active Directory that runs on an EC2 instance, can provide the Active Directory domain. Opcenter can also use an on-premises domain that requires the Active Directory connector to deploy to the VPC.

Opcenter uses SQL Server as its primary database platform. Amazon Relational Database Service (Amazon RDS) for SQL Server provides a managed service and automates routine database tasks. Opcenter uses a highly available Multi-Availability Zone instance deployment. You can make all three Availability Zones available to the Multi-Availability Zone database. Separate security groups and network ACLs add network protection to the database.

The optional Overall Equipment Efficiency application requires specialized database configurations beyond those that are provided by standard Amazon RDS. Amazon RDS Custom supports these requirements.

Amazon Aurora PostgreSQL-Compatible Edition is a fully managed relational database engine that’s compatible with PostgreSQL. You can use it as a cost-effective alternative to SQL Server. You can also use Amazon RDS for PostgreSQL.

Users across customer offices and shop floor locations can use web browsers to access the MES in the cloud. You can allow access to Opcenter Execution over the public internet, but customers can choose to only allow connections from their own sites. For private connectivity, customers can use AWS Site-to-Site VPN, AWS Direct Connect, or a combination of both. Direct Connect doesn’t use the public internet so that it can provide predictable latency and bandwidth. Organizations can deploy multiple connections to combine both technologies for enhanced resilience. An Application Load Balancer in the cloud receives and distributes client traffic to the application servers. Because of the stateful nature of the applications, you must provide session stickiness on the Application Load Balancer. You can also allow connections in the opposite direction from the MES to on-premises systems, such as ERP or OPC-UA servers.

The Opcenter deployment benefits from the following services for name resolution, data protection, observability, instance management, and security:

• An Amazon Route 53 private zone provides name resolution for both on-premises clients and MES components. It resolves the load balancer's name for external clients and facilitates internal communication between MES servers.

• AWS Backup automates the protection of Opcenter servers and any S3 buckets that OC CN MOM uses. For databases, both AWS Backup and Amazon RDS automated backups support continuous backup and point-in-time recovery (PITR) capabilities.

• Amazon CloudWatch monitors your deployment by collecting logs and metrics from EC2 instances, Amazon RDS databases, and other solution components. It provides operational health insights and automated responses to performance and resource changes.

• AWS CloudTrail supports governance and compliance by tracking user activity and API usage across your deployment.

• AWS Systems Manager manages EC2 instances, enabling patch management, automated operational commands, and secure remote access. This reduces the need for SSH key management and additional firewall rules.

• AWS Identity and Access Management (IAM) enforces secure access control to AWS resources and APIs. IAM permissions define allowed actions, such as EC2 instance creation or S3 bucket content management.

Opcenter Execution on Outposts

When on-premises deployment is necessary, Outposts supports MES installation at customer locations and provides proximity to shop floor operations and control over data residency. Customers retain access to familiar AWS management tools to maintain consistent developer and administrator experiences. Outposts extends AWS infrastructure, services, APIs, and tools to customer premises as a fully managed service. It provides local access to AWS managed infrastructure. Outposts allows customers to run applications with the same management tools that they used in their AWS Regions, and also use on-premises compute and storage for reduced latency and local data processing. The following figure illustrates the architecture for deploying Siemens Opcenter Execution on Outposts.

Outposts deploys AWS compute and storage capacity at customer sites with the same hardware as public AWS Regions. As an extension of a Region, AWS fully manages, monitors, and operates each Outposts deployment. While Outposts offers both server and rack form factors, Siemens Opcenter Execution requires a rack configuration. The preceding figure depicts an Outposts rack deployment in the customer environment on the diagram's right side.

An Outposts rack functions as an extension of an Availability Zone. The rack requires a network connection, known as the service link, to connect the rack to an anchor point in the Availability Zone. This service link allows the Outposts service to monitor and manage the rack, and support all AWS API calls from local resources. The connection must use either the public internet, AWS Direct Connect, or a combination of both, with resilient connectivity strongly recommended for continuous operations. Site-to-Site VPN isn’t supported for this link. If the service link fails, then all AWS API operations become unavailable.

After you deploy Outposts and establish the connections, you can provision EC2 instances, storage, databases, and other resources locally. This is similar to what you do in a Region's Availability Zone. When you create local subnets, you extend a Regional virtual private cloud (VPC) to the Outpost and provide a unified VPC that spans both cloud and on-premises environments. All communications between Regional and Outposts resources within this shared VPC flow through the service link.

The Opcenter deployment on Outposts separates applications across EC2 instances: OC CN MOM and the license server separate to OP EX FN/DS/PR. Multiple instances can provide server-level redundancy, though all instances reside in the same physical rack. The optional OC EX FN OEE application runs on a separate EC2 instance. If required, then you can create local S3 buckets with Amazon S3 on Outposts to make sure that data remains on premises. Note that this feature is available only on first-generation racks. Outposts racks offer Amazon EBS gp2 volumes for first-generation racks.

Outposts supports the same network security controls as Regions, including security groups and network ACLs. Outposts also supports Auto Scaling groups and launch templates for automated instance management.

While Amazon RDS is available on Outposts, Outposts doesn’t currently support Amazon RDS Custom and Amazon Aurora PostgreSQL-Compatible. For OC EX FN OEE deployments, you can install the database on a dedicated EC2 instance, as illustrated in the preceding figure. All database-managed data remains within Outposts. Native backup tools can store backups either on Outposts or in on-premises locations.

When you deploy without the OEE module, Amazon RDS for Microsoft SQL Server or Amazon RDS for PostgreSQL can manage the database, and all managed data remains on premises. Amazon RDS stores automated backups in the Region. This is an important consideration when you have data residency requirements. Amazon RDS supports automated local backups on Outposts for PostgreSQL. It also supports native backup and restore in SQL Server, and Amazon RDS stores these backups in Amazon S3 in the Outpost or on-premises storage.

Outposts provides a second network connection in addition to the service link. The local gateway provides direct communication between on-premises networks and Outposts resources. This connection supports low-latency connections between the MES and clients, shop floor devices, and OPC-UA servers. While both connections share physical interfaces, they operate on separate VLANs for traffic isolation.

Outposts offers two options for local gateway connectivity between on-premises networks and Outposts resources: Direct VPC routing and customer-owned IP pools. Both options are compatible with Opcenter Execution. For more information, see How to choose between CoIP and Direct VPC routing modes on AWS Outposts rack.

Opcenter servers can reach the internet through two routes: Through the local gateway and on-premises network, or through a NAT gateway in the parent Region's Availability Zone. All AWS API calls route through the service link, regardless of the chosen internet path. On-premises clients connect to the MES through the local gateway. While Outposts supports Application Load Balancers, it currently doesn't support the sticky sessions feature that’s a requirement when deploying multiple OP EX FN/DS/PR servers. To address this drawback, the architecture implements an EC2-hosted proxy server that provides path-based routing and session stickiness. You can also use an on-premises load balancer.

The Opcenter servers that run in Outposts can use an Active Directory domain in the Region that AWS Directory Service for Microsoft Active Directory provides. They can also use an Active Directory that runs on an EC2 instance. The servers can also connect directly to an on-premises domain through the local gateway.

As in Regional deployments, a Route 53 private zone manages hostname resolution for the load balancer and servers. However, because default resolvers reside in the Region, they require round-trip DNS requests that add latency and depend on Regional connectivity. Deploying a Route 53 resolver on Outposts provides local address caching for Outposts resources, peered VPC resources, and public internet addresses. Note that this deployment is available only on first-generation racks. This local resolver reduces latency and maintains DNS resolution, even if the Outpost becomes disconnected from the Region. On-premises DNS servers is an alternative solution that requires you to configure DHCP option sets to turn on Opcenter servers to use the on-premises DNS servers.

AWS Backup automates resource backups on Outposts and stores them in the associated Region. For local backup storage, you can store the EBS snapshots of servers in Amazon S3 on Outposts. Alternative commercial or open-source backup tools allow you to store backups in Outposts-based Amazon EBS, Amazon S3, or on-premises network storage. These options confirm compliance with data residency requirements while maintaining operational resilience.

Outposts supports the key operational services: CloudWatch for monitoring and observability, CloudTrail for activity tracking, and Systems Manager for instance management.

Data residency

A key advantage of Outposts is control over data location. This feature is critical for data residency requirements. The MES deployment can make sure that all data remains on premises through strategic architectural choices. The deployment stores all data in the database, or in S3 buckets, and on the application servers. All these components run and store data within the Outpost, with backup options available to either the Outpost or on-premises network storage. This architecture prevents data from reaching the Region, as needed by compliance standards.

Low-latency connectivity

The local gateway connects the Outpost to the on-premises network. This connection allows consistent, low-latency communication between the MES and shop floor components, such as devices and OPC-UA servers.

Disconnected Outposts

Outposts expects continuous Regional connectivity through the service link. The impact of any disconnection depends on the outage duration and architectural decisions that you make during MES deployment. During a disconnection, EC2 instances and EBS volumes on Outposts continue running, but AWS API operations become unavailable. This prevents instance deployment or termination and blocks operations that require IAM authorization, including S3 bucket access. While applications that don't require the API calls remain operational, services that depend on Regional IAM authentication become inaccessible. Because Amazon S3 usage is optional in Opcenter deployments, consider the criticality of functions that depend on Amazon S3 when you design for disconnection scenarios.

The local gateway maintains connectivity between the on-premises network and MES. However, EC2 instances that are configured to use the service link for internet access lose their internet connectivity. While the Route 53 zone resides in the Region, deploying a Route 53 resolver in the Outpost maintains DNS resolution during a disconnection. If address changes occur during the disconnection period, then cached IP addresses can become stale.

If you use Amazon RDS, then the database continues to run, and applications can access the database. Administrative actions, such as creation or modification of a database, become unavailable. Amazon RDS backups don’t run, and Amazon RDS suspends automatic instance replacement for failed databases. Applications that use Route 53 for database connectivity require a local Route 53 resolver to maintain DNS resolution. During a disconnection, Outposts can’t transfer logs and metrics to CloudWatch. However, it retains this operational data locally for up to 7 days, and automatically forwards the data to CloudWatch after connectivity is restored.

Systems Manager can’t manage EC2 instances on Outposts during a disconnection.

Multiple Outposts

While the architecture that the article describes uses a single Outposts rack, you can install multiple racks in different physical locations to achieve higher availability. Each Outposts rack connects to a different Availability Zone in the Region so that application components can be distributed across racks. This is similar to the Availability Zone distribution when you deploy Opcenter Execution in a Region. If you have a Multi-Availability Zone configuration and use Amazon RDS, then you need a customer-owned IP pool. For more information, see AWS Outposts high availability design and architecture considerations.

Conclusion

Deploying MES on AWS infrastructure offers manufacturers enhanced flexibility, resilience, and cost-effectiveness. This article demonstrates how to implement Siemens Opcenter Execution in two scenarios: Within a Region, and on Outposts for on-premises solutions by meeting specific data residency or low-latency requirements.

For more information about Siemens Opcenter Execution on AWS, see the following resources:

Guidance for deploying Siemens Opcenter Execution foundation on AWS

Cloud-based MES: Opcenter Execution for process and discrete industries on AWS

Deploying an MES in the cloud and at the edge on AWS Outposts (AWS re:Invent 2024).

For information on Outposts, see AWS Outposts family documentation. Contact your AWS account team for further information and support.

---

About the author

Dave Watson

Dave Watson serves as a Principal Specialist Solutions Architect at AWS within the Industry Specialists and Solutions team. He specializes in the smart manufacturing and product engineering domains, and helps customers transform their operations through cloud technologies. Before AWS, Dave architected and delivered solutions for manufacturing and assembly facilities, with a focus on increasing production capacity and operational efficiency while reducing risk. He also led a major industrial software vendor’s migration to the cloud.