APR Sept/Oct 2023 - 38

»
BIOPHARMACEUTICAL
»
Automated/Closed Aseptic Processing
Closed processing using closed aseptic transfer technology. Less
stringent environmental requirements (ISO 7/8) and reduced human
interventions. Validation of closed systems and process steps -
functionally " closed " :
* Demonstrate integrity of closed production and aseptic
interfaces between the unit systems throughout lifecycle of use
and under full range of operating conditions
* Recommend performing APS as part of the initial validation of
closed systems
Aseptic Process Scale-Up/Scale-Out
Does the quality system have the capacity to support process scale-up/
scale-out for the manufacturing process: where are the bottle-necks?
* Scalability by size/volume (scale-up)
* Have the aseptic connections changed?
* Has the mass transfer frequency increased?
* APS may be required along with PPQ and media hold studies
* Scalability by adding parallel processing culture systems
(scale-out)
* Simulation to demonstrate capacity is dependent on the risks of
cross-contamination (e.g., facility design, HVAC coverage)
* Define and test at maximum capacity
APS requirements and strategies during process scale-up/scaleout
will be highly dependent on process-specific, facility-specific
risk assessments.
Connecting OT and IT in
Process Applications
Connecting operational technology (OT) with information technology
(IT) in process applications offers many distinct advantages for
processing plants. While technology has made the task easier, there
are still challenges to consider. The following several best practices can
save plant operators a lot of headaches down the road.
It is best practice for connecting OT and IT system integration software
for real-time data communications and the interplay of OT and IT in
modern plants.
The more important one is timely access to information. If you isolate
IT and OT networks, you end up with communications between
them being human-mediated. This means slow communications and
incomplete information that's prone to errors. There's a real advantage
to getting that information directly from OT into IT, and from IT back
into OT. Obviously, for production planning, resource management,
safety monitoring analytics, and fault prediction, not everybody needs
38 |
| September/October 2023
real-time data, but there's a big advantage to not having to wait until
the end of a shift or the end of the day to gain production insights.
One of the rules of communicating between IT and OT is that the
OT network should never have a direct Internet connection. This
means you must route data through IT to get to some of the upand-coming
services such as artificial intelligence (AI) systems15,16
that are cloud-based, or centralized monitoring where there are
multiple, geographically diverse locations, centralized reporting and
aggregation of data from different sources. All these need a mechanism
to get data out to those processing locations, but you don't want that
to be a direct connection out of OT.
This issue stands in the way when companies deal with need to share
data with third parties. They've got suppliers or customers, who want
access to the real-time information coming off their processes, either
for just-in-time supply or for insight into what the process is doing.
Customers want to know what to expect. But they need a transmission
path that isn't exposed to the risks associated with the Internet.
There are three items that could be classified as availability, security
and reliability. Availability is effectively the ability to provide data when
it's required in a form its consumers can use. This means designing
networks that can deliver the data, and choosing protocols that deliver
it in a usable form.
The protocol you choose will affect the network topology. Or, if you
have a certain network topology in mind, that's going to limit the
protocols you can choose. If you want a cloud service, it may expect a
direct connection from OT into the cloud, which is not desirable, and
will impact security.
Security and availability are inversely correlated. The more available
you want to make your data, the less secure it's going to be and vice
versa. So, you must adjust your availability requirements according
to your security needs. When we look at something like industrial
protocols, typically they're not designed with the goal of sharing data
across networks. They're typically client/server designs, which are
inappropriate when the server is in the protected network. You don't
want to reach into the OT network to collect data from a server. You are
going to end up with a mix of protocols depending on the leg of the
journey your data is taking. So, all the way from the PLC or DCS right
up to a cloud or an analysis system, you may need different protocols
for each segment of the path the data traverses.
Then there's a reliability issue-preserving data during disconnections.
If you lose a network connection or you have a hardware failure, you
want to preserve as much data as you can during that time. That
typically means you want to have store-and-forward capability for
data, so you can deal with a network loss. Redundancy is required, so
you should have multiple data paths. If one path goes down, the other
is available.
Once again, the choice of protocol determines how much redundancy
or what sort of store-and-forward you can offer/afford. That again,
limits the protocol choices. If you rely on a particular vendor's
redundancy solution, e.g., it may limit your security capabilities or your
network topology.
APR Sept/Oct 2023

Table of Contents for the Digital Edition of APR Sept/Oct 2023
