Aspen InfoPlus.21^® is just another process historian, right? It collects data about your process (temperatures, pressures, etc.), stores it on disk and makes it available for trending, reporting and other analyses. There’s not much else to say: process historians are process historians. But are they?

 

To believe this about Aspen InfoPlus.21 is to do a great injustice to one of our coolest, most powerful and most misunderstood products!

 

Let’s start at the beginning…

 

If you have any experience with object-oriented software, which effectively means any experience of programming from the last decade or more, then you will feel right at home because, in essence, Aspen InfoPlus.21 is an object-oriented database — with one important difference.

 

If I was teaching a class, I would write "It’s an object"  in the upper-left corner of the whiteboard, circle it in red and leave it there for the duration of the course. This makes it easy to answer questions that will come up, like:

 

• How do you read data from the plant equipment?

• How do you name the properties of an object?

• How do you create enumerations for integer data (like “No/Yes,” “Off/On,” “OK/Alarm,” etc.)?

• How do you specify how many decimal places are displayed by default for a floating-point property?

• How do you set up X-bar/range/CUSUM/EWMA processing to detect and raise SPC alarms in the background?

 

It’s all done with objects, and if you are familiar with object-oriented design then you know that objects are defined by classes. What are classes? (Points to the upper-left corner of the board.)

 

 

The Properties of Classes

 

It all starts with a class called DefinitionDef. This is the root class of the whole database and defines all the other classes in the system. All classes follow the same pattern.

 

They are all defined by DefinitionDef (including DefinitionDef itself) and, in turn, define their own objects. The difference between this and pure object-oriented systems is inheritance, or lack thereof. The class hierarchy in Aspen InfoPlus.21 is only two levels deep, but in practice this makes the system extremely efficient.

 

All objects have state, which is to say they have their own data, which can be the usual integers, strings or floats, as well as other objects. There’s a header containing properties (fields) such as its name, and properties that are required to support the task for which the object is intended.

 

Objects can have zero or more arrays of structured data. For example, an object that describes a piece of plant equipment might have an array of references to other equipment objects.

 

Objects can have zero or more stacks of time-series data that gets pushed down as new data arrives. When I tell you that Aspen InfoPlus.21 can happily push well over 4 million values a second without breaking a sweat (where a value is a property, a timestamp and quality information) you can see why it’s so great at modeling real-time processes. A class can have multiple stacks of data; for example, it could have a stack of every single raw value read from the plant that is only stored for 12 months, as well as a second stack containing “compressed” data that is stored forever. It’s up to you.

 

 

The Capability to Scale

 

At this point, Aspen InfoPlus.21 looks like any other object-oriented database, albeit one that performs extremely well. But where it gets really interesting is that in addition to state, classes can have behavior. Objects can not only be read from and written to, but they can also be activated. Activated objects perform some class-specific function.

 

All the rich functionality within an Aspen InfoPlus.21 system comes from its classes and their associated behaviors. But this raises a critical question: How do you scale all this? Systems can contain hundreds of thousands, or even millions of objects. How does it process all that data to disk quickly enough, and how does it process all those activations?

 

Aspen InfoPlus.21 relies heavily on parallel processing at the operating system level. Too much data coming from the DCS? Create a second, third or fourth interface to clustered data servers and spread the load between them. Too many script objects for one OS process to handle? Create 10 of them and spread the load — maybe you want all the objects that have to respond instantly on the first five, then spread out the remaining objects over the other five. Too much data coming in for the disk to handle at one time? Create more history objects that store data on their own independent physical disks. It makes no difference which disk data is stored in because access is always through the single data object within the database.

 

In the majority of cases you only need one process because the SQLplus language is extremely efficient, but it’s good to know the flexibility and scalability is there.

 

 

Instant Functionality

 

Out of the box, you get hundreds of classes that do everything from monitoring the health of the system to driving OEE and SPC functionality. On top of that you can create your own classes to do whatever you need.

 

Once I was asked if I could do something about a broken multiplexor out on plant. It had two incoming temperature signals and used the same wiring to transfer the data to a collector which then de-multiplexed it back out into separate tags. The problem was that a couple of times a day the multiplexor got out of whack (yes, that’s a technical term), and the temperature reading that should have gone into Tag 1 ended up in Tag 2 and vice versa. This made it appear that the process had suddenly spiked, and the quality management system (implemented in a set of classes and objects, obviously) downgraded the product as a result.

 

The correct decision would have been to find and fix the multiplexor, but it was an old plant, no one knew where the multiplexor was, and it would have been too much work in any case. Luckily, in Aspen InfoPlus.21 it was easy to create a class and associated object to reference the two incoming tags, execute a short script every time new data arrived, perform a sanity check (did the two tags suddenly spike in equal and opposite directions?) and drive two new tags with the incoming data in the right places. All downstream functionality then referenced the new tags. Easy!

 

 

 

Learn more about Aspen InfoPlus.21.