This Guidance demonstrates how to set up cloud-based Programmable Logic Controllers (PLC) management and code development using the software-as-a-service (SaaS) product, Software Defined Automation (SDA). With SDA, you can securely access PLC code from anywhere using any device over an operational technology (OT) network. You can deploy code updates to hundreds of PLCs in minutes, reducing factory downtime and increasing productivity. SDA PLC management helps you integrate automated deployments in your continuous integration/continuous deployment (CI/CD) process.

Please note: [Disclaimer]

Architecture Diagram

[Architecture diagram description]

Download the architecture diagram PDF 

Well-Architected Pillars

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

  • SDA uses automation to minimize human error and ensure consistency. Amazon CloudWatch collects logs, metrics, and events, which are consolidated in a central system and transformed into actionable key performance indicators (KPIs) and alarms. Critical alarms are relayed in near-real-time to SDA’s operations team, helping ensure immediate attention and response. User data automatic backups are made in a secondary AWS Region every hour.

    Read the Operational Excellence whitepaper 
  • SDA extensively employs managed services, substantially reducing your operational burden. Amazon Cognito enables user authentication, and all API calls undergo an authentication and authorization process. User authorizations are fine-grained and can be set permanently or on a time-based schedule. All data in transfer and at rest is encrypted. 

    Additionally, the connection from the cloud to the factory is enabled by a secure, short-lived VPN tunnel created on demand by users. Once the operation on the PLC is complete, the tunnel is automatically destroyed.

    Read the Security whitepaper 
  • SDA uses AWS managed services that benefit from the inherent availability and reliability provided by AWS service teams. For self-managed services, SDA deploys resources across three distinct Availability Zones within an AWS Region. This distributed and load-balanced approach enables automatic replacement of malfunctioning resources and dynamic scaling based on demand.

    Read the Reliability whitepaper 
  • Whether using AWS managed or self-managed services, SDA uses real-time usage metrics to right-size resources. This architecture's flexibility helps you swiftly adapt to and integrate new offerings, such as the latest EC2 instance generations. You can benefit from peak platform performance at competitive prices, all while maintaining a focus on sustainability.

    Read the Performance Efficiency whitepaper 
  • As a subscription-based SaaS provider, SDA focuses on cost efficiency in its operations. By maximizing price-to-performance ratios with AWS resources, we help ensure savings that directly benefit customers. We prioritized the utilization of serverless services that offer automatic scaling and a pay-as-you-go model, meaning you only pay for the resources you use without having to worry about long-term or upfront commitments. We analyzed usage patterns, established baseline requirements, and instituted scheduled and dynamic auto-scaling policies that adapt swiftly to change in demand. This approach helps ensure that only necessary resources are allocated, eliminating wasteful idle capacities.

    Read the Cost Optimization whitepaper 
  • Because SDA only uses serverless services, resources are only consumed when necessary, reducing energy usage and waste. Cloud elasticity reduces operational costs but also contributes significantly to reduce the energy footprint of this Guidance. In the long run, this strategy aids in minimizing environmental impact through optimal resource utilization and lowering carbon emissions associated with data center operations.

    Read the Sustainability whitepaper 

Implementation Resources

A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.

The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.

[Content Type]

[Title]

This [blog post/e-book/Guidance/sample code] demonstrates how [insert short description].

Disclaimer

The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.

References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.

Was this page helpful?