Final Year Capstone Project

Bachelor of Technology – Process Automation Technology
McMaster University
4TR3 Capstone Design Project
Final Report - MonitorIT
Professor: Tom Wanyama
Submitted by: Lawrence Cheuk 001215072
Partners: Taher Banatwala 001145543
Omar Ziena 001224131
Date: December 7, 2016

Declaration of Authorship
I Taher Banatwala (001145543), Lawrence Cheuk (001215072), and Omar Ziena (001224131)
certify that this material is my original work. No other person's work has been used without due
acknowledgement. I have not made my work available to anyone else.
Taher Banatwala Lawrence Cheuk Omar Ziena
---------------------------------------------- ---------------------------------------------- ----------------------------------------------
Taher Banatwala Lawrence Cheuk Omar Ziena
001145543 001215072 001224131

Abstract
With the fourth industrial revolution underway, companies must remain at the forefront of
emerging technologies. The final capstone project aimed to create an automated pharmaceutical
bottling process with the main functional objective of creating a real-time production database to
monitor and analyze data beyond the factory floor. The mechanical aspect of the project was
completed by incorporating an existing SMC Bottling Assembly into the pharmaceutical design.
An Allen-Bradley PLC Controller and I/O module was used to wire the necessary inputs and
outputs to complete the process of loading the assembly with bottles, filling the bottle with a
forecasted volume of medication, securing the cap, recording production cycle data, and loading a
completed pallet. The information manipulation aspect of the concept includes loading real-time
data from RSLogix and medical diagnosis to KEPServerEX OPC Server, where Cogent DataHub
OPC Client’s data historian, HMI, and webpage can access the data. Data can be analyzed by a
company’s department to find trends, estimations and production problems. In order for
organizations to maintain a competitive edge in their respective industries, deliver products to
clients on time and to keep the network continuously operating, real-time data monitoring,
analytics, and informed decisions are essential tools.

Table of Contents
Abstract........................................................................................................................................... 3
Summary of Report......................................................................................................................... 5
1 Introduction.................................................................................................................................. 6
2 Project Background & Literature Review.................................................................................... 8
3 Project Implementation.............................................................................................................. 11
3.1 Initial Design....................................................................................................................... 11
3.2 Modified Design.................................................................................................................. 11
3.3 Prototype Development....................................................................................................... 13
3.4 System Development........................................................................................................... 14
4 Discussion.................................................................................................................................. 29
5 Timeline..................................................................................................................................... 31
5.1 Technical Implementation – September 2016..................................................................... 31
5.2 Issues Encountered.............................................................................................................. 33
6 Conclusion ................................................................................................................................. 35
7 References.................................................................................................................................. 36
8 Appendix.................................................................................................................................... 37
8.1 Scripting .............................................................................................................................. 37

5 | P a g e
Summary of Report
Emerging technologies drive businesses and industries forward into the future and if an industry
fails to adopt trending technologies, it will suffer greatly. The pharmaceutical industry is one that
is known to be reluctant to adopt new technologies and has remained stagnant for the past decade.
Until recently have they begun to implement the benefits and potential of the fourth industrial
revolution.
The MonitorIT concept adapted industry 4.0 design principles to responsively monitor a
pharmaceutical bottling line process via Cogent DataHub’s WebView HMI, accessible from
anywhere in the world. Data collected from production was stored and updated within a data
historian and analyzed against real-time illness diagnosis to forecast future demands. Data
analytics were performed on the various sets of collected data to provide relevant visual trends to
management up to level 3 of the ISA-95 functional hierarchy (with the potential of reaching level
4). This method would allow companies to more effectively and efficiently adjust their resources
if needed, improve current process, analyze data and protect the company’s assets and utilities.
A few of the design objectives implemented, but not limited to included:
 The process must be safe and easy to operate
 Selection and Storage of production data in the database
 Visualization, alarm and presentation of production data
 Data analysis and indication of production trends
 Data analysis and indication of real-time trends
 Forecast future demand
 Automate production decisions
A manufacturing company with constantly changing demands, such as the pharmaceutical
industry, depends greatly on adopting information based decision making. Time and money cannot
be wasted on constantly making poor decisions. In order for organizations to maintain a
competitive edge within their respective industries, deliver products to clients in a timely manner,
and to keep the network continuously operating, real-time data monitoring, analytics, and informed
decisions are essential tools.

6 | P a g e
1 Introduction
Emerging technologies drive businesses and industries forward into the future and if an industry
fails to adopt trending technologies, it will suffer greatly. The pharmaceutical industry is one that
is known to be reluctant to adopt new technologies and has remained stagnant for the past decade.
Until recently have they begun to implement the benefits and potential of the fourth industrial
revolution. Before any medication is delivered to hospitals or shelves of local pharmacies,
pharmaceutical plants must ensure their manufacturing process is safe and as efficient as possible
from the preparation of basic materials through to the final packaging. Manufacturing operations
that are being completed using computerized and automated systems programmed by the plant
technician are now controlled by information, cloud-computing, and Big Data Analytics. Due to
this emerging technological revolution used to create modern medicine and the demand for quality
products the final year capstone project was based on the information manipulation of the
pharmaceutical manufacturing process, specifically production volume.
The pharmaceutical bottling system consisted
of the following stations/assemblies; a servo
motor mounted on a rotating plate with six
equidistant bottle stations controlled by 60-
degrees of rotation, stopping from the Liquid
Dispensing Station to the Cap Pusher. The
Bottle Dispensing Station housed empty
bottles by loading them vertically in a
cylindrical extrusion and controlled by a
pneumatic cylinder with a mounted sheet
metal plate. Once the bottle entered the rotary
plate it continues to the Liquid Dispensing
Station where the volume of medication
desired was controlled via an electronic
valve. After the liquid has filled the bottle, it
continues to the Cap Placing station, where
Image 1 – Rotary Plate
Image 2 – Cap Placing & Cap Pusher
Assemblies

7 | P a g e
the caps are stacked similarly to the Bottle Dispensing Station. Once the caps have been placed
onto the bottle, the Cap Pusher would press down and seal the cap. A gripper would then pick the
bottle up and move it to be palletized. The palletization assembly consisted of two drivers
controlling the X- and Y-axis movement of the Vacuum Arm that would pick up the completed
bottle and place it on the pallet. All stations, statuses, and production volume was monitored and
controlled via Cogent DataHub’s WebView HMI and production data was stored within the data
historian. The HMI, which was accessible from anywhere with an internet connection, was
designed with an Operator View and Plant Manager View. The Operator View allowed plant floor
level access and control to the production, while the Plant Manager View allowed management to
monitor the historical and real-time production trends for informed decision making.
Image 3 – Bottle Dispensing Station Image 4 – Gripper Station
Image 5 – Palletization Image 6 – Full Bottling System

8 | P a g e
2 Project Background & Literature Review
The worth of the global pharmaceutical market is US$300 billion a year, a figure expected to rise
to US$400 billion within three years [1]. Today’s pharmaceutical companies are moving away
from manufactured in large volumes into a new generation of specialty medicine, recognizing the
need to develop more personalized treatments. However, traditional manufacturing and quality
control will struggle to keep up with innovation in personalized treatments unless there is a change.
This is where the potential of ‘Industry 4.0’ as the next big trend has to revolutionize
pharmaceutical operations [2].
The initiative behind the fourth industrial revolution, or Industry 4.0, is to connect human
resources, data, and physical machines in a cyber-physical network. The literature review
identified four key components: Cyber-Physical Systems, Internet of Things, Internet of Services,
and Smart Factory. One of which, the ‘Internet of Things’, will establish intelligent machine-to-
machine connectivity within and beyond company walls [3], [4]. Having a network of connected
devices within pharmaceutical manufacturing facilities allows remote access to equipment,
proactive maintenance based on stored logs and analytics, real-time plant visibility, the ability to
recognize and immediately respond to compliance issues, and monitor and control serialization.
The resulting analytics from these connected devices can be used to improve business and
manufacturing efficiency, reduce risk and essentially disrupt aging business models [5]. The
Industry 4.0 concept is comprised of six design principles: Interoperability, Virtualization,
Decentralization, Real-Time Capability, Service Orientation, and Modularity; all of which aim to
build and execute a Smart Factory for all modern day manufacturing processes [3]. Before
adopting any new technology, the pharmaceutical industry thoroughly studies risks, pros and cons,
etc. But now as companies are being compelled to streamline their process, reduce costs and
control the industry’s rising challenges, they are finding new ways to optimize complex processes
by adopting cloud computing [6]. By applying the concepts of Industry 4.0 to the pharmaceutical
industry, “Pharma 4.0” is both revolutionary and transformational from the output of goods to the
information feedback of real-time data [2].
According to Robert Gaertner [4], Director of Strategy for Quality and Manufacturing at Veeva
Systems, “By leveraging cloud-based data management and advanced analytics, key information

9 | P a g e
can be generated going beyond compliance and supporting quality decisions and continuous
improvement.” However, in order to successfully implement Pharma 4.0, especially cloud-based
computing, the pharmaceutical industry must adopt the Open Platform Communication (OPC), a
series of standards and specifications for industrial telecommunication. The OPC Foundation [7]
describes the OPC as “the interoperability standard for the secure and reliable exchange of data in
the industrial automation space and in other industries. It is platform independent and ensures the
seamless flow of information among devices from multiple vendors. These specifications define
the interface between Clients and Servers, as well as Servers and Servers, including access to real-
time data, monitoring of alarms and events, access to historical data and other applications.” An
OPC Server is a software application written to OPC Specifications, which will respond to
requests, and provide data to one or more OPC Clients in a standard, consistent manner. Any
compliant OPC Client can interface with, and request data from any compliant OPC Server,
regardless of the vendor, or underlying system providing the data. The original intent was for the
Process Automation industry, to provide a standard interface for devices, such as a PLC, DCS,
HMI, SCADA, RTU or DAS. Since it is no longer only unique for this industry to require a
standard interface to obtain data from a system, OPC Servers are now available for countless other
systems including historians, relational databases, RFID scanners, file systems, enterprise
applications, custom devices, building control systems, IT networks, robots, even road signs [8].
An industry that does not remain in the forefront of emerging technologies will struggle and a
Pharma 4.0 approach is needed within the pharmaceutical industry to support the transition from
robust but inflexible mass-production processes to more agile, highly automated methods that
create tailored products swiftly and cost-effectively with the expected quality, safety, and
efficiency [9]. Modern information and communication technologies like Cyber-Physical Systems,
Big Data or Cloud Computing will help predict the possibility to increase productivity, quality and
flexibility within manufacturing, leading to understanding advantages within the competition.
Quality needs to mandate the assessment of risks and the implementation of effective controls to
open the doors to Pharma 4.0 [2]. It is the right time for the next industrial revolution and a radical
revamping of technical operations from the inside out.
Every year about 35 million deaths occur due to Non Communicable Diseases (NCDs), with about
80% of these deaths occur in low- and middle-income countries. Most of the conditions which

10 | P a g e
cause these deaths can be treated with essential medicines. Public sector access to the medication
to these chronic disease is poor in most low- and middle-income countries because of a lack of
public resources or under-budgeting, inaccurate demand forecasting, and inefficient procurement
and distribution [10]. The Capstone design aimed to leverage the industry 4.0 paradigm to resolve
the cause of preventable deaths due to NCDs by implementing five out of the six design principles:
Interoperability – Where individual processes of the packaging and the operator were able to
connect with each other through the Internet of Things and Internet of Services, which allowed
access to plant floor visibility from anywhere in the world.
Virtualization – Due to time-constraints, it was difficult to create an entire virtual world, therefore,
only one aspect of the real world was used to link to the virtual plant model. The virtual model
included the conditions of all the cyber-physical systems in the production process and drew data
from health organization websites that detail illness diagnosis.
Real-Time Capability – All data was monitored and displayed in real time and analyzed in real-
time for any production irregularities.
Service Orientation – A web server HMI that detailed the production data in a user-friendly format
and email notifications were created to offer individuals both internally and externally across
company borders a view of the packaging service.
Decentralization – Demand forecasting allowed the system to automate its own production and
decisions.

11 | P a g e
3 Project Implementation
3.1 Initial Design
The initial concept of MonitorIT intended to implement the following design objectives:
 The process must be safe and easy to operate
 Data collection with minimal human intervention
 Selection and storage of production data in a database
 Visualization and presentation of production data
 Data analysis and indication of production trends
 Automate SMC assembly
 Detect and successfully reject defectives
 Calculate power consumed and $/kwh
One major component of the initial design was the replacement
of the gripper station (Image 7) with a load sensor to measure
defective bottles during production. The change in the resistance
of the strain gauge would provide an electrical value and convert
the bottle acting on it into an electrical signal read by the PLC.
Values outside the tolerence limit would be rejected via a double
acting cylinder with a mounted angular sheet metal plate to reject
the bottle. Values within the limit would proceed to the
palletizing station. Energy consumption was also intended to be measured in real-time and
compared against peak and non-peak hours from energy provider websites to automate cost
savings decisions and budget resources of the production line.
3.2 Modified Design
The initial design objectives to detect and reject defectives and to calculate power consumed
evolved into forecasting medicinal demand based on real-time diagnosis and automating
production volume decisions. Which as a result, also meant retaining the Gripper Station. The
modifications were made specifically to tackle a current real world issue regarding non
Image 7 – Gripper Station

12 | P a g e
communicable diseases (NCDs). Up to 35 million deaths that occur due to NCDs are preventable
with proper budgeting, and demand forecasting. The modified design objectives aimed to leverage
industry 4.0 to potentially forecast and budget the demand for NCD medication. Due to this
concept evolution, one processed bottle represented one month of production volume and two
common NCD’s where chosen to produce medication for: Cardiovascular Disease and Malignant
Neoplasms. Depending on the forecast demanded, under the assumption that the process
encompassed 10% of the total population diagnosed for each disease, the main functions of the
concept were as followed:
1. Bottle Tracking / Filling
Using the provided stations on the SMC Automated Assembly, tracking the bottle
throughout the process was accomplished via a proximity sensor at the Capsule Dispensing
Station. The volume of liquid dispensed was dependent on the result of the multiple
regression analysis from historical production data and real time diagnosis data. The
resulting forecast demanded was bridged to adjust the preset value of the timer controlling
the electronic valve. This process allowed the tracking of each bottle (monthly production
cycle), and total production volume.
2. Bottle Palletizing
A Vacuum Arm, controlled by two drivers for the X- and Y-axis respectively, would pick
up the bottle from the Gripper Station and place it onto the production pallet. This bottle
would represent the end of one monthly production cycle.
3. Real Time Production Data
The production data (i.e. production volume, medication type, station statuses, etc.) was
gathered by an OPC server on the same network as the PLC and stored within a data
historian to be used for trend analysis and production forecasting. Monthly completed
production data and production targets were emailed to management and operators for
continual active decision making. The processed data was also displayed on a web HMI,
accessible from anywhere in the world.

13 | P a g e
3.3 Prototype Development
There were several specific
components required to implement
the MonitorIT service into the
pharmaceutical bottling line. One of
the most important components was
the Rockwell Soft Logix PLC that
was used to control the SMC
assembly. The PLC came preloaded
with a program that was able to
control the assembly in its current
state modifications were required as
per the changes made to the
assembly. Bridged data controlling
the electronic valve required the
code to be modified to reflect this change in the control strategy. The next component that was
imperative to this project was the OPC server and client to log data in real time. KEPServerEX
and Cogent DataHub were used as the OPC server and client respectively on a computer near the
SMC assembly addressed on the same network as the PLC. Cogent DataHub WebView is a
Microsoft Silver light application, which allowed the creation of HMI systems developed and
delivered within a web browser program. The feature allowed the access of data anywhere on the
internet while everything was hosted and driven by Cogent DataHub. All the HMI page design
and editing was done on Internet Explorer and page updates were automatically published as soon
as changes were saved. Since the computer and PLC were on the same network, the OPC client
was used to log values directly from tags created from the OPC server from the PLC. All the tags
that were logged on the OPC client were viewable on Cogent DataHub. All stations, statuses, and
production volume was monitored and controlled via a web HMI and production data was stored
within the data historian. The HMI was designed with an Operator View and Plant Manager View.
The Operator View allowed plant floor level access and control to the production, while the Plant
Manager View allowed management to Alarms and warnings were also displayed on this screen.
Image 8 – System Architecture

14 | P a g e
Real-time diagnosis of Cardiovascular disease and Malignant Neoplasm were taken from health
organization websites and updated through an Excel VBA. Multiple regression analysis of the
diagnosis data and historical production data was used to forecast the production demand of the
next month. This data was bridged to the timer that controlled the electronic valve of the Liquid
Dispensing Station to distribute the predicted volume for each of the two diseases.
3.4 System Development
Figure 1 illustrates the PLC code that was downloaded to the Micrologix 1500 on Station 1 in the
system. The major blocks in this figure show the 15 second TON timer that was used to control
almost every part on this station. The logic used was comparing the accumulation of the timer
against certain preset settings and when the timer was in a specific accumulation range, the
corresponding output would trigger. For example, when the timer accumulation is greater than or
equal to 1, and less than or equal to 2, the bottle dispenser bit is activated. This application of logic
provided a 2 second window for each bottle to drop without getting stuck in the tube or dropping
during a rotation of the plate. The logic described can be seen in Figure 2 below.
Figure 1 - Station 1 PLC Code
Figure 2 - Timer values compared

15 | P a g e
The palletization process consisted of one main routine, illustrated in Figure 3, accompanied by three subroutines, the Table, Translation,
and Location ladder logic, shown in Figures 4, 5, and 6 respectively. Two drivers controlled the X- and Y-axis, dubbed the Table and
Translation Axis respectively, of the Vacuum Arm and a remote was used to teach the locations of the 5x5 pallet. Each single taught
location energized four output bits, with two bits for each axis. The bits were represented by a number and a letter and were represented
as followed: Table 1A, 1B, 1C, 1D, 2A for the X-axis direction and Trans 1A, 1B, 1C, 1D, 2A for the Y-axis direction. The main
program would initiate when the sensor for the Gripper Station became energized, which would active Table 1A and Trans 2B, the four-
bit location of the Gripper Station. The Vacuum Arm would move to pick up the bottle from the station and place it in one of the
locations defined on the 5x5 pallet.
Figure 3 – Palletization Main Program Figure 4 – Location Subroutine

16 | P a g e
Figure 5 – Table-Axis Subroutine Figure 6 – Translation-Axis Subroutine
Figure 5 and 6 illustrates the logic behind the activation of the defined locations, as a counter for the bottle determined the desired
location. One complete row across the Table-axis was filled in sequence before moving onto the next. This logic implied that the Trans
locations (bit activation) remained the same until the table row completed its sequence. Once the desired location was reached, the
Location Subroutine would activate the Position Reached Bit, which energizes the Vacuum Arm from the Main Program to move down
and place the bottle at the desired location. Each location was represented by two input bits, which correspond to the letters of the Table
and Trans location.

17 | P a g e
Before data manipulation and collection could begin, real-time data of Cardiovascular Disease and
Malignant Neoplasm had to be collected. This was accomplished via an Excel VBA program, as
exemplified in Figure 7. Three VBA modules were written, each to collect data from the past day,
past month, and past year. All three modules essentially opened an instance of Internet Explorer
to navigate to the website hosting the live data and run the JavaScript within the website’s HTML
code that was responsible for updating the specified disease diagnosis. Once the JavaScript was
called, the VBA program extracted the value and entered it into the Excel worksheet. In order to
automatically update the Excel worksheet in real-time, a timer code was implemented to rerun the
three modules every two seconds (Figure 8). This data was used for the production forecast.
Figure 7 – Excel VBA Program
Figure 8 – Excel Timer Update

18 | P a g e
After the PLC programming was completed in RSLogix 500, an OPC server had to be setup to
host the live values of all the bits in the PLC program to provide real-time monitoring. This was
one of the major applications of the project. A new channel was created using the built in client
configuration in KepServer. Additionally, two devices were created on the channel with the
appropriate network settings to connect KEPServer to the 1761-NET-ENI Ethernet modules on
the PLC rack of each station. The individual stations are denoted as “S1” and “S2” as can be seen
in Figure 10. The network architecture is quite simple. The Ethernet modules were connected to
an Ethernet switch and then the switch was hooked up to the computer that the KepServer client
was running on. The network port that was connected to the switch was put on the same subnet as
the Ethernet modules and assigned an unused IP on that subnet.
Figure 10 - KepServerEX Main Screen
Figure 11 - Tag Creation in KepServerEx
Figure 9 - Channel Configuration in
KepServerEX

19 | P a g e
After configuring the devices with the appropriate network settings, and confirming that the
devices were responding to the KepServer, tags had to be added for monitoring. Unfortunately,
due to the Ethernet network configuration, it was not possible to send I/O bits from the PLC to the
OPC Server as Ethernet does not support the transmission of individual bits. To overcome this
limitation, new PLC code was implemented that changed the value of an integer depending on the
state of a corresponding input or output. In Figure 12, it is shown that when the STOP bit is active,
a 1 is moved using the MOV instruction to integer N7:12. This integer is what is monitored in
KepServer and further used in Cogent to monitor the states of the Stop bit. Similar logic was
implemented for every input/output in both stations.
Figure 12 - Bits to Integer Ladder Logic
To monitor the live values in the OPC Server, the Quick Client, seen in Figure 13, was used to
ensure that the values being read in KepServer matched the bit states in RSLogix 500. The quick
client was an extremely useful tool in the implementation stage of this project as it provided a
medium between Cogent and the PLC that could host values, and KepServer has read and most
importantly write access to bits in the PLC, which a functionality that Cogent does not provide.
The write access was fundamental for the success of the project as in the final steps, values from
an excel file had to be sent to the PLC to make changes to fill setpoints in real time. The ladder
logic used for this can be seen in Figure 14.

20 | P a g e
Figure 13 - Quick Client
Figure 14 - Excel Values changing fill setpoint

21 | P a g e
Figure 15 and 16 show the setup of the OPC client in Cogent
Datahub. Cogent was the OPC client in our network
architecture. All the live values from KepServer were hosted
in Cogent and stored in the Historian that is a functionality of
Cogent. These stored values were accessed further on in the
project but this will be discussed later.
Figure 15 - Cogent Datahub OPC Properties
Figure 17 and 18 exhibit the DDE client that was configured to host the Excel values into Cogent.
These Excel values in turn were being pulled from a data website that had relevant data for the
process but this is discussed in further detail later in the report. For the configuration of the DDE
client a point name had to be provided “Topic” that the client would refer to. When using the Excel
Service, the Topic is usually the Filename, but in scenarios where the excel file has multiple sheets
the topic can be increased in scope to refer to that specific sheet in the file. After the Topic is set,
the DDE items have to be added in the Definition window (see: Figure 18). The string entered for
the Point Name in the Item Definition Window has to exactly match the string entered for the
specific cell in the excel file. Instead of referring to a string in the point name, the cell value can
also be referenced. For example, instead of DailyCardioTarget, A1 could have been used instead.
Figure 17 - DDE Client Main Page Figure 18 - DDE Client Configuration
Figure 16 - Cogent Datahub OPC
Client Configuration

22 | P a g e
Figure 19 - Bridging values to KepServerEx
After the required values were hosted in Cogent, they had to be bridged to KepServerEx so that
the values could be sent to the PLC. As mentioned earlier, KepServer has read and write access to
the PLC whereas Cogent only has read access. Due to this lack of functionality on Cogent’s part,
Bridging was used to connect the value coming from excel to an empty float register on the PLC.
Figure 20 - Reading values from KepServerEx

23 | P a g e
The logic displayed in Figure 20 was used to read the values from KepServer. The values shown
were updating in the excel file, which in turn would update the value in the PLC. This allowed the
process to react to real time changes in demand and change the production levels for each cycle.
Figure 21 - Changing valve open time
In Figure 21, the Fill Timer Preset value is changed when the Scaled Production value being read
from the excel file reaches 2000. 2000 is an arbitrary setpoint that was decided upon by the group.
This setpoint can be changed as more data is gathered about production trends the longer the
system is online. This data is stored in the historian and can be accessed at any time.
Figure 22 - Configuring automatic emails

24 | P a g e
In Figure 22 and 23 the automatic email configuration is shown. The email system is supported as
a functionality through Cogent Datahub. Recipients can be added or removed in the configuration,
a message can be written, and values that are being monitored in the OPC client can be sent in the
email. For this project, the value sent in the email was the Production Volume Totalizer that was
being monitored in the PLC. It was sent to the recipients using Gmail’s SMTP server over port
465 which is the standard port for Gmail SMTP communication. The email is triggered off the
Bottle Sensor bit on Station 2 which represents a full month of production in the system. This
email service can also be used to alert operators of any alarms that turn on in the system but this
was not in the scope of the project.
Figure 23 - Configuring Email Trigger

25 | P a g e
The HMI consisted of three pages; Home
Page, Production Plant and Production
Data. WebView contains standard
controls, and industry standard symbols,
which were configured to recognize
condition states. Property binding, allows
specifying graphical interactions between controls. Objects/Controls were associated with input
and output values of the PLC tags collected through the OPC connectivity (Figure 24).
Scripting was required to animate the logical sequence of the events that occur in the production
line. WebView included scripting capabilities, supported by S# (Script.NET), which allowed
custom behavior of applications and enables programmatic interaction with objects, therefore,
creating a more engaged user experience. Scripting functions were added to Cogent/Animation.ss
file to animate the position of the bottles as they go along the production line. Hidden text fields
were created, which binded its value to a script for example:
/* Causes this script to assign a value to myBottle@ContentX changes */
Public void SETP (
String propertyReference,
Object value
)
If (VAL ("default: Channel1.S1.Bottle Dispenser") == 0) {
SETP ("myBottle1@ContentX", 80);
SETP ("myBottle1@ContentY", 395);
}
/* Run Animation */
var from = null;
var to = null;
var time = null;
If (VAL ("default: Channel1.S1.Bottle Dispenser") == 1) {
from = 390;
to = 80;
time= 2;
wvAnimation.Run (new DoubleAnimation (),
“myBottle@ContentY”, from, to, TimeSpan.FromSeconds (time));
}
Figure 24 – OPC to WebView Connection

26 | P a g e
SETP function assigns a value to the named property. The value will be coerced to the type of the
target property, myBottle before being assigned. The function includes the following parameters,
the qualified property to set and the property value. Property reference usually takes the form of
elementname@propertyname, however elementname is optional. When the bottle dispenser value
is equal to zero (Figure 25), the function assigns an initial position of bottle (myBottle) at 80 in the
X direction (ContentX) and 345 in the Y (ContentY). wvAnimation.Run function requires the
following arguments in order to be successfully executed, since the animation of the bottle requires
a movement of a numeric value, DoubleAnimation() is used as one of the parameters. The second
argument, target indicates the handle or the object that is to be manipulated, in this case the bottle
(myBottle). The third and fourth arguments define the movement in position from one point to
another. The final argument is a time span, which is an indication of how long the animation should
run for. When the value of the Bottle Dispenser is equal to 1, the bottle transitions from position
390 to 80 in the Y direction for a time span of 2 seconds. As the bottle is being dispensed the color
of the object changes from transparent (when the input value is 0) to green (when the input value
is 1), an indication that the station is currently active (Figure 25).
The Progress Value of the bottle is bound via point value of water valve in the second station,
Bottle Filler. The progress color is set to blue, the minimum value (ProgressMin) of the progress
is 0 and the maximum value (ProgressMax) is 1.2 (Figure 27). Once the water valve becomes
active, the bottle will fill as long as the bit remains true (Figure 26).
Figure 25 – Animation of the Bottle Dispenser Station
Figure 26 – Bottle Filler Animation

27 | P a g e
Similar to the Bottle Dispenser station, the sequence of the Capper station, Cap Press, Bottle
Gripper was logically identical.
Once the gripper places the bottle onto the weighing station, the actuator picks and places the bottle
on the pallet. The bottles are represented as circular objects, which are initially non visible. When
the gripper reaches the desired position, the bottles become visible as represented in Figure 31.
Figure 27 – Bottle Filler Station Configuration
Figure 28 – Capper Animation Figure 29 – Cap Press Animation
Figure 30 – Gripper Animation

28 | P a g e
Figure 32 represents a quick overview of the current active stations, the proximity sensor and
stations start blinking once a bottle is detected present and any input from the 5 stations are active.
Lastly in the HMI design, buttons are configured to allow the transition from one page to another.
Production Plant page is utilized on the plant floor to give visibility to production process, however
Production Data page represents key performance data and trends (Figure 33).
Figure 31 – Pallet Animation
Figure 32 – Overview of the system animation
Figure 33 – HMI Pages

29 | P a g e
4 Discussion
The viability of implementing production data manipulation over a network is high, because it is
not only restricted to pharmaceutical manufacturing, but can be applied to various manufacturing,
and process control industries. In addition, the pharmaceutical industry is adapting the fourth
industrial revolution, calling it Pharma 4.0., an industrial revolution to connect all recourses into
one virtual network. The MonitorIT project is directly in line with the revolution and up-to-date
with the current industrial technologies used today. The concept automated the process, created a
database system to monitor the plant floor remotely, and stored relevant data and trends on one
network.
The entire concept of the design was to adapt Pharma 4.0 but on a smaller and more realistic scale,
constrained by time and resources of the course. Five of the six design principles of Industry 4.0
was used within MonitorIT. These design principles support companies in identifying and
implementing Industry 4.0 scenarios. Each design principle was implemented to a certain degree,
such that it showcased the ability of the enablers of Industry 4.0. The first design principle,
Interoperability, was showcased through the communication of the different packaging stations
(i.e. capping, filling, etc.) and humans through leveraging the Internet of Services by creating a
web HMI. Virtualization was demonstrated through the creation of a virtual model collecting data
relayed from the sensors to RSLogix, and then automatically placing the data onto the OPC server
and act as the conditions of all the cyber-physical systems. The real world virtualization was simply
to take the live number of diagnosed patients with Cardiovascular Disease and Malignant
Neoplasm such that the production demand of the associated medication would be forecasted
and/or changed automatically. Real-time capability was accomplished through RSLogix and Excel
VBA, and taken a step further by creating OPC Clients to retrieve said data to be displayed on web
pages and a non-local HMI. The production data was compared to expected production parameters
to analyze for any irregularities. The webpage portion also demonstrated the Service Orientation
design principle, where the production data was offered to humans both internally and across
company borders a view of the packaging service in a user-friendly format. Decentralization was
a bit more difficult to implement due to various constraints, however the current solution that
showcased a portion of it was by implementing multiple regression analysis on the historical

30 | P a g e
production data and real-time diagnosis data to forecast and change the production volume
automatically. The only issue was that there was not enough time to have the system physically
utilize a medicinal change immediately.
Everyday there are large amounts of data generated by machines waiting to be collected such as
feed rates, motor speeds, downtime, part counts, operator logs for production notes, quality, scrap
and more. Collecting and analyzing this data manually can be complex and does not provide
immediate feedback. Real time machine monitoring allows management to instantly identify
issues as they occur. Management can receive notification via, email or text if a machine is down
or use collected production data for data analysis. The advantage of software based machine
monitoring is that it collects and organizes important data digitally while providing real time
analysis and notifications. Today many monitoring machines have the technology built in them to
output the current machine status. Real time machine monitoring systems can read that output,
save it in a database, and then analyze and report on it. The data gathered during the process can
be used to calculate the overall efficiency of the system, and through statistical management, can
make critical decisions and foresee future problems regarding their production process.
Potential future challenges in implementation can occur during the manipulation of the data once
the tags are created. Problems such as data loss, data corruption, data security and maintaining
integrity of production may occur. To eliminate this risk from happening, backup files need be
created to prevent data loss. In order to prevent data corruption and security automation control
processes must keep up with the current technology and security systems provided. In addition,
there may be a learning curve for programming statistical computing and data analysis, specifically
with summarizing and aggregating data, merging files by key variables, and most importantly the
complexity of programming and debugging with software programs companies are not familiar
with. To prevent this issue from occurring companies must familiarize themselves with current
industry standard programming practices and take advantage of all the resources available. Lastly,
designs face hardware malfunctioning, as parts and components wear out over time, therefore
maintenance and regular checks are necessary to ensure optimum functionality.

31 | P a g e
5 Timeline
Table 1: Initial Timeline
Date of Completion Tasks
9/8/16 Map out I/O of SMC Assembly Station 1 & 2
9/9/16 Begin PLC Program for 1 rotation of 1st
Station
9/15/16
Complete PLC Program for 1st
Station
Begin PLC Program for 2nd
Station
Teach Table and Translation Drivers
9/16/16 Complete test program for Drivers
9/22/16
Complete PLC Program for 2nd
Station
Begin PLC Program (program revisions as required) for full bottle
automation
9/23/16
Troubleshoot and continue Full PLC Program
Latest date to order load sensor, Ethernet switch, and other required
parts as needed
9/29/16 Complete Full PLC Program
9/30/16 Test and finalize Full PLC Program
10/6/16 Begin querying necessary data from PLC
10/7/16
Begin HMI creation
Begin Ignition Programming
10/11/16 – 10/14/16 Complete HMI
10/20/16
Program SQL Database, Data Analysis, and UI
10/21/16
10/27/16
10/28/16
11/3/16
11/4/16
11/10/16
11/11/16 Complete Ignition Programming
11/17/16 Conduct Preliminary Test
11/18/16
Carry out action items as required from preliminary test
Conduct Final Test 1
11/24/16 Conduct Final Test 2
5.1 Technical Implementation – September 2016
At the beginning of the term the project was still not underway. The PLC program that was present on the
PLC was not able to meet the specification of the project so it had to be scrapped. Both stations were
programmed from scratch using ladder logic, with the first station working within a week. There were
some issues encountered with the palletizing station as the controllers that moved the linear actuators for

32 | P a g e
the vacuum arm were not robust in design. Another major change to the design from last term was the
exclusion of the pill dispensing station and making the project geared towards liquid dispensing. The
decision was made to save time on the design and instead focus on making the IIOT component of our
project more robust. The Micrologix 1500 PLC’s came with the SMC assembly and RSLogix 500 was
used to program the PLC’s. Both PLC’s were connected to the computer station through an Ethernet
switch and interfaced with the 1761-ENI Ethernet card that was present on the SMC assembly.
Taher – For the first two weeks, Taher’s main responsibility was to program the first SMC assembly.
Taher wrote the code for that program from scratch, tested it, and made the necessary changes to make
sure that the assembly was working efficiently.
After the programming for the first assembly was finished, Taher collaborated with Omar to research
different OPC software that could be used for the project and tried to arrange a license. Omar and Taher
were in talks with Inductive Automation to get a free license for their Ignition software but unfortunately
Ignition was not compatible with Micrologix 1500 and had to find an alternative. Omar and Taher found
a few different OPC servers such as Matronix and Kepware that were compatible for our project.
Lawrence – Lawrence was responsible for learning how to work with the controllers that controlled the
actuators for the vacuum arm on the second SMC assembly. A manual was supplied and Lawrence taught
himself how to use the controllers to program the different positions that were needed to place bottles at
on the pallet. Lawrence was also the lead on the PLC programming for the second SMC assembly as he
gained the most experience with the controllers. With Lawrence’s experience with the controllers and
assistance from Omar and Taher, the program for the second station was completed from scratch as well.
After the programming for the SMC assembly was finished, Lawrence moved onto helping Omar and
Taher with the setup of the OPC Server to connect to the PLC and be able to read the tags that we required.
Omar – For the first few weeks Omar worked alongside Taher to get the first SMC assembly programmed
and conducted research into Ignition and other OPC software that were considered for the project. Omar
also worked with Lawrence and aided him with learning how to efficiently work with the actuator
controller. Omar, Taher, and Lawrence all worked together on the PLC program for the second SMC
assembly.

33 | P a g e
Table 2 – Modified Timeline: Beginning October 2016
Date of Completion Tasks
9/30/16 Test and finalize Full PLC Program
10/6/16 Test connection of KEPServerEX and create tags
10/7/16
Finalize KEPServerEX connection
Begin Cogent DataHub Client Implementation
10/11/16 – 10/14/16
Begin HMI Design
Begin Excel VBA Programming
10/20/16
Complete HMI – Operator View
10/21/16
10/27/16
10/28/16
11/3/16 Complete Excel VBA Program
11/4/16 Implement Data Historian and Email Notification
11/10/16 Complete HMI – Management View
11/11/16 Complete Production Forecast Programming
11/17/16 Conduct Preliminary Test
11/18/16
Carry out action items as required from preliminary test
Conduct Final Test 1
11/24/16 Conduct Final Test 2
5.2 Issues Encountered
The project was extensively tested over the several weeks. Simulations on the first assembly were run to
find the precise amount of time required and each station and then checked that against bottlenecks that
were present in the system. With further testing it was found that there was a 15 second delay for each
rotation as that was the largest bottleneck in the process and cannot be minimized any further.
Different configurations for the pallet to determine which one gave the most efficient system were also
tested. Since the X- and Y-axis had independent controllers, the program was setup similar to a matrix,
starting whichever way was deemed acceptable. With this level of control, the spots needed to be used on
the pallet were able to be programmed. One major problem that occurred was that the vacuum arm was
setup to energize specific inputs on for each position and some of the positions used the same input. This
flaw in the wiring on the table made it impossible to use two positions that had the same input being turned
on, as the program became conflicted between the arm that was already at the position and where it needed
to move to. As a result, with this limitation there were only a few spots on the pallet that were actually
available to be used.

34 | P a g e
Various OPC software were tested to see which one would work best. Ignition, KEPServerEX,
MatronixOPC, Matronix Data Manager, and Cogent Datahub were all examined. There was the most
success with Kepware and MatronixOPC due to the simple setup of the server. One problem that was
encountered during testing was that any Boolean bits from the PLC in our OPC server cannot be read.
This was due to communication over Ethernet IP, which made it such that only word bytes could be
communicated. Due to this, all the bits that needed to be recorded from the PLC program required an extra
rung to be added with a MOV Function to energize a word byte to represent the data.
During the data manipulation phase of the project, issues were encountered when programming the HMI.
The S# language required a learning curve in order to script the animations for the web HMI. The process
required the entire month of October to adapt, as seen in Table 2. Numerous email communications were
sent between Omar and a representative from Cogent DataHub before Omar became accustomed to the
language. Furthermore, issues were encountered when writing the Excel VBA such that the variables for
Past Day, Past Month, and Past Year became conflicted with one another and displayed each other’s value
instead of their own. This was found to be due to the multiple Internet Explorer instances opened which
confused the program’s addressing value for the HTML.

35 | P a g e
6 Conclusion
The aim was to research, design, and develop an independent project that incorporates and showcases the
different learning outcomes that the students have picked up over the course of 4 years. This project has
been researched extensively, which led to the outcome of designing methods to enable Industry 4.0
infrastructure into the capstone. Although the project is only based for the pharmaceutical industry, the
knowledge gained has many real-world applications, with companies using big data analytics, machine to
machine communication, data monitoring, and process control. Additionally, multiple presentations were
held to exhibit the conceptual design features, project objectives, and method of implementation. The
constructive feedback from the presentations has allowed the conceptual design of MonitorIT to win 3rd
place at the ISA Expo. This demonstrates that the project is headed in the right direction.
In conclusions, a manufacturing company with constantly changing demands, such as the pharmaceutical
industry, depends greatly on making information based decision. Time and money cannot be wasted on
constantly making poor decisions, or travelling to the factory floor from the enterprise level. Furthermore,
Operators and IT departments can’t afford to waste production time to manually determine an issue with
the functionality of the physical system. However, a server is virtual and organizations must be able to
gain accesses and insights as quickly as possible before production loss. In order for organizations to
maintain a competitive edge in their respective industries, deliver products to clients on time and to keep
the network continuously operating, real-time data monitoring, analytics, and informed decisions are
essential tools.

36 | P a g e
7 References
[1] WHO, "Pharmaceutical Industry," in World Health Organization, World Health Organization, 2010.
[Online]. Available: http://www.who.int/trade/glossary/story073/en/. Accessed: Feb. 29, 2016.
[2] R. Gaertner, "Pharma 4.0: Quality Management in the Digital Age," in EPM, EPM Magazine, 2015.
[Online]. Available: http://www.epmmagazine.com/opinion/quality-management/. Accessed: Feb. 29, 2016.
[3] M. Hermann, T. Pentek, and B. Otto, "Design Principles for Industrie 4.0 Scenarios," 2015. [Online].
Available: http://www.snom.mb.tu-dortmund.de/cms/de/forschung/Arbeitsberichte/Design-Principles-for-
Industrie-4_0-Scenarios.pdf. Accessed: Feb. 29, 2016.
[4] R. Gaertner, "Pharma 4.0 – time to rethink manufacturing and quality," in Veeva Systems, 2016. [Online].
Available: https://www.veeva.com/eu/wp-content/uploads/2016/01/Manufacturing-Chemist-Pharma-4.0-
1.pdf. Accessed: Feb. 29, 2016.
[5] K. Langhauser, "Industrial Internet of things: Buzzwords have feelings, too," in Pharmaceutical
Manufacturing, Pharma Manufacturing, 2015. [Online]. Available:
http://www.pharmamanufacturing.com/articles/2015/industrial-internet-of-things-buzzwords/. Accessed: Feb.
29, 2016.
[6] R. Singit, "Cloud computing in Pharma," Pharma Manufacturing, 2015. [Online]. Available:
http://www.pharmamanufacturing.com/articles/2015/cloud-computing-in-pharma/. Accessed: Feb. 29, 2016.
[7] OPC Foundation, "What is OPC?," OPC Foundation, 2016. [Online]. Available:
https://opcfoundation.org/about/what-is-opc/. Accessed: Feb. 29, 2016.
[8] MatrikonOPC, "OPC server and OPC client relationship," 2005. [Online]. Available:
http://www.matrikonopc.com/resources/opc-server.aspx. Accessed: Feb. 29, 2016.
[9] E. Smith, "Quality management in the digital age," Pharma Manufacturing, 2015. [Online]. Available:
http://www.pharmamanufacturing.com/articles/2015/pharma-4-0-quality-management-in-the-digital-age/.
Accessed: Feb. 29, 2016.
[10] “Access to non communicable diseases medicines,” World Health Organization. [Online]. Available:
http://www.who.int/medicines/areas/policy/access_noncommunicable/en/. Accessed: Feb. 29, 2016.

37 | P a g e
8 Appendix
8.1 Scripting
STATION 1: Bottle Dispenser
if (VAL("default:Channel1.S1.Bottle Dispenser") == 0 )
{
SETP("myBottle1@ContentX",80);
SETP("myBottle1@ContentY",395);
}
if (VAL("default:Channel1.S1.Bottle Dispenser") ==1)
{
wvAnimation.Run(new DoubleAnimation(),
"myBottle1@ContentY", 390, 433, TimeSpan.FromSeconds(2));
}
STATION 3: Capper
if (VAL("default:Channel1.S1.Bottle Cap Dispenser") ==0)
{
SETP("myCap@ContentY",395);
SETP("myCap@ContentX",273);
}
if (VAL("default:Channel1.S1.Bottle Cap Dispenser") ==1)
{
"myCap@ContentY", 395, 430, TimeSpan.FromSeconds(1));
}
STATION 4: Cap Press
if (VAL("default:Channel1.S1.Cap Press") == 1 )
{
"CapPress@ContentY", 330, 355, TimeSpan.FromSeconds(1));
}
if (VAL("default:Channel1.S1.Cap Press") ==0)
{
"CapPress@ContentY", 355, 330, TimeSpan.FromSeconds(1));
}

38 | P a g e
STATION 5: Gripper
if (VAL("default:Channel1.S1.Arm Down") == 0 && VAL("default:Channel1.S1.Arm Out") == 0 &&
VAL("default:Channel1.S2.Bottle Sensor") == 0)
{
SETP("myBottle4@ContentX",528.5);
SETP("Gripper@ContentY",294);
SETP("Gripper@ContentX",537);
SETP("Gripper2@ContentX",667);
SETP("Gripper2@ContentY",294);
SETP("myBottle5@ContentX",747);
}
if (VAL("default:Channel1.S1.Arm Down") == 1 && VAL("default:Channel1.S1.Arm Out") == 0)
{
"Gripper@ContentY", 294, 367, TimeSpan.FromSeconds(1));
}
if (VAL("default:Channel1.S1.Arm Down") == 0 && VAL("default:Channel1.S1.Gripper") ==1 &&
VAL("default:Channel1.S1.Arm Out") ==0 )
{
"Gripper@ContentY", 367, 294, TimeSpan.FromSeconds(1));
"myBottle4@ContentY", 432, 358, TimeSpan.FromSeconds(1));
}
if (VAL("default:Channel1.S1.Arm Out") == 1 && VAL("default:Channel1.S1.Arm Down") ==1 &&
VAL("default:Channel1.S1.Gripper") ==1)
{
"myBottle5@ContentY", 357,406 , TimeSpan.FromSeconds(1));
"Gripper2@ContentY", 294,344 , TimeSpan.FromSeconds(1));

39 | P a g e
}
if (VAL("default:Channel1.S1.Arm Out") == 1 && VAL("default:Channel1.S1.Arm Down") ==0 &&
VAL("default:Channel1.S1.Gripper") ==0)
{
"Gripper2@ContentY", 344,294 , TimeSpan.FromSeconds(1));

Final Year Capstone Project

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Final Year Capstone Project

Ähnlich wie Final Year Capstone Project (20)

Final Year Capstone Project