Most of us use cloud services in our daily lives. Our email, music, financial software, and shopping are regularly becoming a browser experience or a data connected mobile app. This paradigm is now moving into for our automation platforms but what shape will it take as it pertains to Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).
SaaS is something we use whenever we go to Gmail, Spotify, QuickBooks Online, PayPal or other applications that are running on the web. In these applications, we are subscribing to a cloud based software application. While we perform these operations, there no way of knowing how its developers wrote the software, where it is running, or even the operating system below it. There is a limited number of features that can be performed.
IaaS accounts are provided by companies like Microsoft, Amazon, or Google allowing developers to run virtual machines (VMs) of their choosing. With these accounts, you can spin up a Linux or Windows VM on a virtual computer with user specified memory, storage, and number of cores. Normally, you pick from templates that are pre-configured and then tweak them to your needs, point them to your static IP address, and configure your virtual network settings. It is far less time consuming than the desktop version of the process but it still requires above average information technology and networking skill.
SaaS and IaaS provide services at opposite ends of the requirements spectrum.
SaaS offers ease of use for end users to get things done. IaaS offers fully flexible systems for developers to create “do it yourself” solutions. The slowest to emerge paradigm is found in the area between SaaS and IaaS, advanced configuration of software using PaaS. In the desktop world, if you are an Excel expert and want to automate your worksheets with macros; you turn on developer mode and run VBA. You can then email these macros to your peers so they can marvel at your prowess. The analogy in cloud based Google Sheets is to automate using Google App scripts. These are JavaScript routines written within the Google Apps platform to provide automation. Since these scripts work on an App platform that lives in the cloud they are a PaaS. You are able to create new data structures, read in values from external sources, write custom reports, manipulate values in the spreadsheets, share results with others and a wide range of other advanced functions all by logging into your Google account. No need to know the operating system, information technology, or networking details.
PaaS makes sense in Automated Manufacturing too.
Controllers, drives, and sensors are easily set up to talk to each other with IP technologies; turn them on and set an address. Currently, the infrastructure part of an automation platform is mired in complexity. When it comes time to create a secure server that hosts the operator screens, databases, and analytics engines which allow these devices to be abundantly more beneficial, a wide range of questions must be answered. Where will it be hosted? What OS will be used? How will it communicate? What drivers are needed? Even if you want to decouple the computer choices by virtualizing the solution you must first create the custom images and set security settings. You are setting up an IaaS for the site.
What if the Automation Server was a PaaS paradigm?
If you could power up an Automation Server image, either hosted by someone else or running within your building then you wouldn’t know or care what OS it is running, how the databases are set up for history services, screen development or recipe management. You would just log into the Automation PaaS and start to configure your system. Furthermore, with appropriate authentication, you could query automation values, access reports, and even supply parameters that the Automation PaaS passes on to the control algorithms. This direction makes complete sense since no one really wants the corporate infrastructure to dictate the automation infrastructure or vice versa.
What will it take for PaaS to emerge in Automation?
Just as in the internet environment, Automation Suppliers must embrace the concept and create the platform. This is certainly an investment but not something that could be done given the VM approach already utilized by many equipment suppliers. The other challenge will be support. On the one hand, system problems will fall into the laps of the PaaS service provider but on the other hand there will only be one configuration to support. There is also the opportunity for simplifying and capitalizing on a more extensible licensing model if the PaaS fully developed by the Automation supplier. It seems like a win-win to me.
{{cta(‘a739d702-5e52-4eda-8613-9997d8548b56’)}}
