In a recent blog post, Terry Orchard covered one of the programming options available on the groov EPIC: secure shell (SSH) access. If you’re familiar with Linux shell commands, you can use secure shell access to install application packages and add functionality to your groov EPIC Edge Programmable Industrial Controller.

For example, you could add a local database server.

In this blog post, we’ll look at reasons why you might want to install a SQL database server using SSH and run it on your EPIC controller. We'll also talk about some considerations you need to keep in mind. 

To get our creative juices flowing, let’s look at some possible uses for a local database server on your groov EPIC processor.

Scheduling. Using a database is a simple and powerful way to schedule tasks in the EPIC or across several EPICs. Time stamps can have a single source, and so task scheduling can be precisely timed and executed. 

Batching or recipes. A local database could hold many, many recipes, and you can change recipes with the usual database administration tools rather than downloading new control code each time you want a different recipe run. The recipe could be triggered by an operator or on a timed schedule by reading the local database. 

Logged contextual data. By storing events and signal values and time stamping them, you are in effect making a basic downtime or OEE (Overall Equipment Effectiveness) report right in the database. You can also add external data like barcode scans, work orders, operator interactions, product codes, and so on to establish a more complete picture of an event or data set.

IT Department. If other departments or areas want access to manufacturing data, it is often a lot more straightforward to simply give them access to a database with the information. Database access is often faster and more convenient for them because most departments are familiar with databases and may already have a workflow or set of software tools to access and present the data in a way that works for them.

Store and forward. With a little extra work, you could set up the controller to test network connectivity and, if it goes down, store the data in the database and then forward it once the network is restored. (See my blog post on running full Ignition on the groov EPIC if you want this feature with just a few mouse clicks).

These are just a few benefits from running a local database on the groov EPIC. You can probably think of more that are specific to your needs or application.

What about the downsides?

Are there any gotchas that you might need to watch out for? Here are two that are definitely worth keeping in mind.

• First, you should have a process in place to ensure that the database does not just grow and grow. Storage is limited on all edge devices, so make sure you have a scheduled job to trim the database and keep it from using up all the available disk space.
• Second, if you want external access to the database server, a port must be opened on the groov EPIC firewall. Through groov Manage, we give you full access to the firewall; but be aware that this could be a security issue. At a minimum, you should ensure that you have a very strong username and passphrase in place to keep both the device and data secure. 

As pointed out in Terry’s blog on the topic, secure shell is not for everyone. Unless you have some solid command line experience in Linux, you should consider other options (and EPIC has many). Also, official support is limited to helping you reset your groov EPIC back to factory defaults, so being able to do your own troubleshooting and get help from online resources to solve your problems is going to be an important part of your success. 

Also, you'll need to be running groov EPIC firmware version 1.4.1 or higher to be able to access these packages.

If this sounds like something you have the skill set to tackle and if the advantages to your application are compelling, then we can help. We offer basic installation instructions for both MariaDB and PostgreSQL over on developer.opto22.com

Till next time, Cheers Mate.

P.S. Here's a quick one-page comparison between MariaDB and PostgreSQL that I found helpful.