Ignition: Data Flow Bridge
Production floors has interesting stories to tell, in form of time series data. Once plant floor data (which has a key role), is linked to central database of the organization, it can be used for a variety of purposes, such as:
• Production monitoring: Manufacturers can use plant floor data to monitor the status of their production process in real time. This can help them to
identify and address problems early on.
• Quality control: Manufacturers can use plant floor data to track the quality of their products. This can help them to identify and eliminate the root causes of
quality problems.
• Predictive maintenance: Manufacturers can use plant floor data to predict when equipment is likely to fail. This allows them to schedule maintenance downtime in advance, which can help to reduce downtime and improve
productivity.
• Process improvement: Manufacturers can use plant floor data to identify areas where their production process can be improved. This can help them to reduce costs and improve efficiency with a blend of efficacy.
​
Production Ecosystem
PLC and sensors in the production area which are connected to SCADA provides a great way for effectively controlling the floor management tasks including machine controls, alerts and inventory management, other aspects closely related to production and monitoring.
OPC (Open Platform Communications) is an eminent protocol for the data collection and distribution. Ignition and MES (Manufacturing Execution System) provides cross platform support for equipment management and data integration.
​
Enterprise Resource Planning
Enterprise Resource Planning (ERP) is a software ecosystem that helps to manage core business processes, such as accounting, finance, manufacturing, supply chain management, customer relationship management (CRM), and human resources (HR). ERP systems integrate these different processes into a single system, which provides a unified view of the business and improves communication and collaboration between departments.
​
Communication Between SCADA and ERP
The actual challenge is to design a robust, efficient, scalable, and two-way data flow from production world to the decision-making hierarchy in a secure way. The main purpose for bridging this gap is to present the visibility to higher decision makers for helping the management for better decision making.
​
Conventional Data Pipelines
A traditional data flow between SCADA and ERP central database/ data warehouse
is quite complex to adopt and has multiple stages as shown in the figure:
This is a slow process due to the multiple stages involved and human interaction at various levels cannot be denied. The quality of data is dependent on multiple factors
like:
• File Format Exported From SCADA. Each OEM provides files in their ownspecific format / pattern, there is no standard format or rules to design these export files. It can range from old file formats like (.wsd and .txt) to well defined .xml available on API call.
• Files Transportation. The transportation of files from the export source to destination from which the data flow pipeline can read it.
• Data Pipelines. Some pipelines are not efficient to read SCADA output in the form of (.wsd and .uwd) files. These files must be translated into .csv or .txt
files.
• Structure of The Files. The file structure does not follow any formatting standards. It may vary over the period.
• Data Extraction from Files. Data extracted from the exported files are loaded in the stagging databases. The data in stagging database pass through multiple stages of transformation to acquire the standard format
required for data mart / final data bases.
• Quality. Data quality assurance tests are mandatory to confirm that data has maintained in its good health during the long process of acquisition, extract,
load and transformation. The other hindrance is conventional data flow which has some inherited limitations.
• Design of Input / Output. Design with predefined input and output format may change at any stage, any changes in the definition of input or output coordinates requires reengineering at multiple stages of data pipeline.
• Scalability. To maintain scalability is a hard task for data pipeline programmer.
• Multiple OEMs. Multiple channels are required to cover multiple OEM data flows.
• Data Security. Data access control has to design for each data flow channel and in some cases various stages may have different access control
methodologies.
• Human Error. The data flow is designed and configurated as per requirement of client. Most of the time it involves scripting. This has the inbuilt phenomenon of human error. Therefore, a through QA process is required to ensure good quality of output data.
• Lack of Standardization. Standards implemented at each channel may not coincide with other channels. When handing over to another section / person
a deep study of standards is mandatory for error free data flow and maintenance of data pipeline.
• Batch Data. Due to above mentioned limitations / hurdles, most the conventional data flows work with batch data. Providing the fact close to a
time range varying from few minutes to some hours. Real time processing and visibility of required data is a dream for most of the organizations. It is near to impossible to get the whole system functioning picture available outside the range of SCADA.
​
Ignition and SQL as a Bridge
Ignition tag historian and Ignition SQL bridge module provide a dream solution for a data pipeline from production floor to the databases / data warehouse of the organization. The dynamic capabilities of Ignition platform joined with the strength of SQL databases provides a robust, scalable, standardized, secure and user-friendly data pipeline from SCADA to databases. This translates the whole cumbersome process into simple steps, as described in the figure below:
The SQL Bridge Module
The SQL Bridge Module of Ignition acts as a bridge between OPC data acquired from SCADA and existing SQL databases through the Ignition automation platform. This allows to move data bidirectionally, log large amounts of data, sequence and track production, manage recipes and downtime, scan barcodes, and log large amounts of data.
SQL bridge module resolves the technical issues related to
• Security
• Integrity of data
• Scalability
Ignition gateway provides the facility to connect to multiple databases with appropriate user management rights. The management of database connectivity is quite simple which is responsible for handling data across multiple databases.
​
The Tag Historian Module
The Tag Historian Module allows to transform a SQL database into a high- performance time-series data historian at a fraction of the price of a proprietary historian. The module doesn't require any complex configurations or data modelling to work with a SQL databases.
Tag historian can take care of following areas:
• Partitioning of data
• Insertion of data into active partition
• Record keeping of active and retired tags.
• Tracking of data based on the tag data type.
• Data purging or archiving
• History splitting to manage tag history on two different database
servers.
It does not require any SQL scripts to complete the task. The ease of use and dynamic capabilities makes it highly scalable, robust and efficient.
​
SQL databases
Once the data has landed in the domain of SQL databases it is ready for reporting or further processing as required by the organization data policies.
Key Benefits
The key benefits of Ignition based data pipeline includes:
• Ease of use. The data historian and SQL bridge module are easy to configure and implement.
• Multiple OEMs One Source. Tag historian provides data in standard format irrespective of the OEM. This provides the benefit of converging all information into one data language.
• Scalability. Stress free management of tag and tag historian makes it an ideal case of easy scalability.
• Two-way Communication. SQL bridge module provides the facility of two communication between SQL databases and Ignition.
• Security. A single security provider makes it easy to implement secure and reliable data flow pipelines.
• Error Control. The total path of data is automatic therefore chances of human error are reduced to minimum, the data is available from actual source to reporting without any quality loss.
• Real Time Data. Tag historian makes it possible to work on real time dataand have fully functional production floor available for analysis and reporting.
• Industry Standard Solution. Data flow does not require any documentation or additional training as the solution is implemented with industrial standards.
Real World Examples
​
A two data pipeline between plant floor to database is a powerful tool that can help manufacturers to improve their operations in several ways: here are some examples of how Ignition based data flow has provided the data integration between production equipment and ERP to solve the real-world problems:
• A car manufacturer is using plant floor data to monitor the quality of its welds. The data is used to identify and eliminate the root causes of welding defects.
• A food manufacturer is using plant floor data to track the temperature of its products during production. The data is used to ensure that the products are processed at the correct temperature to maintain food safety.
• A pharmaceutical manufacturer is using plant floor data to predict when its equipment is likely to fail. The data allows the manufacturer to schedule maintenance downtime in advance, which helps to reduce downtime and improve productivity.
• A wind farm management system is using wind data and equipment state to monitor any dip in the actual production verses expected production to locate the real causes, hindering the power production.