COLI

1
Center for Process Analytical Chemistry University
of Washington Box 351700 Seattle, WA
98195-1700 Phone[phone] FAX (206)
543-6506

• COLI

• Chemometrics On-line Iniative

2
What,
How,
Who,
Where
Why,
While the disipline of Chemometrics most
certiantly can be considered mature, it is by no
means static. New advances continue to be
developed at a pace that outstrips the ability of
Chemometic software vendors and process analyzer
vendors to keep up with. Fueled by the
exponential increases in inexpensive
computational power Chemometricians are expanding
the boundaries of data analysis at an equavalent
rate. As a result those who use Chemometric
tools have been relegated to the position of
observers. Techniques that could help solve
problems abound in the literature but to
integrate them into an on-line process analytical
environment is bottle-necked or in many cases
bottle-stopped by the closed archiecture of the
software environments of both the chemometric and
the analyzer vendors. Many users feel that given
the utility of todays software operating system
environments it should be possible to remove
these restrictions in a way that satisfies not
only the users but also the business interests of
the Chemometric software and Analyzer
vendors. COLI has been formed to explore and
hopefully identify a specific mechanism for
achieving this goal.
3
What,
Why,
How,
Who,
Where

• Must be fully inclusive with regards to
  participation without restrictions or conditions
  and completely in the public domain.
• The focus will be to satisfy the requirements for
  on-line process analytics
• Recognize that overlap exists with needs of
  others such as laboratory analytics and encourage
  participation beyond the process analytics
  community
• Must satisfy the IP rights and requirements of
  everyone.
• Integrety of users data
• Chemometric software vendors proprietary
  environment.
• Analyzer vendors proprietary environment
• Everyones proprietary algorithms
• Must be consistent with the business goals of
  both the Chemometric software vendors and the
  analyzer vendors.

4
What, Why, Who, How, Where

• Sponsorship of COLI is under the CPAC Industry
  Initiatives umbrella
• A forum that does not require CPAC membership for
  participation
• All activity will be posted under the CPAC
  Iniatives section on their website
• On-line
• To allow for efficient participation of a
  geographically distributed
• Meetings

5
How Far Have We Come

• Began at meeting in Chicago during summer of 2000
  to discuss work being done with Matlab as a
  Runtime Prediction Engine.
• Matlab Runtime Prediction Engine Model was
  presented at IFPAC 2001
• Created COLI as CPAC initiative summer of 2001
• Sponsors - Mel Koch Dave Veltkamp, CPAC
• Stewardship - Dave Marrow, ExxonMobil Chemical
  Co. Chuck Miller, Dupont
• Steering Committee - 3 Chemometric Software
  Vendors, 3 process analyzer vendors, 11 users
• Rolled out at IFPAC 2002

6
What Are The Next Steps

• Promote participation
• en gauge

7
When developing an on-line process application
the requirements of 2 environments must be
considered. The first is the data analysis/model
development environment (DE). This exists
off-line, generally residing on the analysists PC.
8
Within this environment the analyst who is
interested in developing an on-line predictive
measurement first attempts to separate out the
information contained in the x-block or
instrument data set then attempts to discover if
a relationship exists between the information in
the x-block and the y-block or known property
values and finally to structure this relationship
into a usable predictive model.
9
Generally some type of DE, encapsulated into a
closed archiecture structure is used to in this
process. The main characteristics of the
development environment are the GUI,
preprocessing and model development functions.
GUI
Preprocessing
Model Development
10
While the development environments typically
afford some types of preprocessing capabilities
they dont always optimally satisfy the
requirements of a specific analysis. This is
often accomplished by preprocessing the data
outside of the development environment. This
tends to be inefficient. A more desirable
alternative would be some mechanism that allowed
external preprocessing to be linked into the DE.
11
Similarly the DE offers options with respect to
the data analysis but again because of the closed
archiecture the analyst is limited to those
techniques contained within the program. Idealy
there would be a mechanism whereby external
techniques could be linked into the DE, taking
advantage of all its preprocessing, graphical
and statistical utilities.
12
From the perspective of on-line process analysis
the objective of the work done within the DE is a
model that accurately and reliably generates
predictive results for the properties of interest
from the data collected on an unknown sample and
can be automated under the analyzer process
monitoring software.
Can be deployed in the process analyzer runtime
environment
13
Lets pause for a moment and look at a simplified
model of the process analyzer runtime environment
by considering the functional requirements.

• First there needs to be an overall supervisory
  function to control the operations necessary to
  collect, process and communicate.

• Next there needs to be a mechanism to control the
  sample systems components such as valves
  pressure, temperature flow devices.

• There needs to be a way to communicate
  information to a process control system such as a
  DCS.

• The instrument has to be told when and under what
  conditions to collect data

• There needs to be an operator interface that
  allows the operator to observe what is occuring
  and iniate changes..

• The data and results needs to be archieved

• Each subsystem needs to have a self diagnostics
  capability and a mechanism for reporting its
  health.

• Finally there needs to be a mechanism for
  analyzing the data and generating a set of
  predictive results.

14
Now lets looks a little closer at the runtime
prediction functionality. The Process Analyzer
Supervisor automates the collection of a new data
set on an unknown sample. Before the predictive
model can be applied any external preprocessing
(i.e. preprocessing done on the calibration data
outside the DE) must be applied.
15
add text
16
Historically the Runtime Prediction Engine (RPE)
functionality has been served in only a couple of
ways

• P- and K-matrix solutions were evaluated from a
  regression vector.

• Similiarly simple PLS and PCR models are
  evaluated using the regression vector approach
  with some simple scaling options

• Preprocessing beyond limited scaling has been the
  domain of the Analyzer Vendors software therefor
  not fully integrated.

• Except in special cases the RPE does not generate
  statistical metrics for reliability.

• Each case is unique for each development/runtime
  environment requiring support of many different
  RPEs.

P- K- matrix regression vector
PLS/PCR regression vector
Limited Preprocessing
No statistical metrics
Many different elements
17
The result is that a barrier exists between the
development and runtime environments that
restricts the capabilities of the analyzis
P- K- matrix regression vector
PLS/PCR regression vector
Limited Preprocessing
No statistical metrics
18
Recent enhancements to both the DE and analyzer
support have shrunk but not eliminated this
barrier

• DE software packages are now allowing more
  complete access by the RPE to all aspects.

• Some analyzer vendors now support enhanced RPEs
  that allow this access.

• A working model of an open archiecture DE and
  complmentary RPE has been demonstrated using
  Matlab.

• Other users have developed their own in-house
  approaches.

More access in RPE
Analyzer support for extension
One open archiecture RPE
Other user supported solutions
19
COLIs Objective Is To Completely Remove The
Barriers That Exist Within The Development
Environment And Between the Development
Environment And The RPE

• In-house solutions come close to satisfing the
  functional objectives of COLI but are complex and
  require extensive resources.

• Complexity limits use to those who have necessary
  skills

• Skilled Chemometricians required to continue
  developments

• Skilled programmers required to implement new
  developments

• External proprietary techniques not available
  within these environments

• Complete access by the RPE to the DE
  functionality is a step forward but still imposes
  limitations

• Application specific preprocessing must still be
  done externally to the DE and RPE

• External techniques cannot access the GUI and
  tool rich environment of the DEs

• Cross platform application remains strongly
  dependent on the analyzer software.

20

• Open Access Development Environment Specification
  - OADES

• Universal Runtime Prediction Engine Specification
  - URPES

21

• Fundamentally the Chemometric DE is a toolbox
• We arent advocating .
• Were asking to be allowed to add our own tools
  into the toolbox

22

• Template 1