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 own
specific 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 data
and 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.