Semiconductor Ignition SCADA and MongoDB Integration
An industry-leading semiconductor company utilized MongoDB as the database solution for their production lines. Originally, they had used a custom front-end to interact with the database resulting in an information silo. After they adopted Ignition for their Enterprise level SCADA platform, they decided to rebuild the front end for the MongoDB system in Ignition to give the operators a single software package to interact with.
They relied on Corso Systems for this implementation because of our previous history with the company, our Ignition SCADA experience, and our database integration skills. We were able to integrate the MongoDB instance into Ignition, and replicate the functionality of the original front end using the Ignition Perspective Module—all with zero downtime for the system.
Automated Manipulator Solution
Implementation Summary
The Ignition platform is built from the ground up with database integration in mind. Typically, Ignition is used with standard SQL databases like Microsoft SQL Server, MySQL, or PostgreSQL. In the early 2010s, there was a big push in the consumer technology world for NoSQL databases. The main difference is a standard SQL database requires you to build the database format into tables before you can begin using the database. Each table has a specific set of columns and new data records are added as rows. If you decide to add more columns later, you will need to modify the database. This may result in errors with your database queries if they rely on a specific number of columns.
On the other hand, NoSQL databases allow you to pass in data with any structure and the data will be stored as a “document.” If you are passing in the same data format every time, it will look very similar to a standard SQL database—although you can easily pass in records with additional fields without disrupting your queries. To be a useful tool for the wide range of technology platforms, NoSQL databases typically have ways to interact with them similar to standard SQL databases. MongoDB is no exception.
We were able to take a Java driver available from MongoDB, and use this as the basis of our connection to the MongoDB instance. This is no different than building an interface to any database. We simply had to import the JDBC driver into the Ignition gateway and set up the connection.
Once we had a connection to the database, we worked with the customer to determine what data they needed to get from the system. For the most part, the data was a standard format—with maybe 15% of the records using additional fields. Based on the data requirements, we built the user interface for interacting with the data, to query results from the database, update records, and add new data to the database. From a user perspective, this was no different than a standard SQL database interface. We then built out the scripting engine to handle interacting with the MongoDB database itself—then tested and validated that everything worked as expected.
Where the data was not in the “standard” format and had additional fields available, we built a dynamic view to show the additional fields to the user, and left the fields set to not visible when the user didn’t need to interact with the additional fields.
Results
This project gave the customer access to all of their data through a single interface. We removed information silos across their production lines. This allowed them to easily correlate time series data from their process with data from the MongoDB system to better manage production, overall quality, and throughput of their process.
This approach reduced overall training time for operators and increased visibility for process engineers.
