I took a database class in college. That course stands out in my memory for two reasons. One, Mary, a tall, lanky 19 year old brunette, and two, that I came to hate entities, relationships, Information Modeling and everything else related to databases. Since I was fortunate to work in IA (Industrial Automation) all these years and not IT, I could avoid all that stuff. Life was good.
Except for, like, NOW…
Entities, relationships, Information Modeling, sometimes in the context of a database and sometimes not, are moving into the factory floor right now. It’s not something I welcomed at first but I’ve learned to make peace with it because for one, I can’t stop it, and two, I have to admit that this kind of technology offers some amazing productivity enhancements.
In the recent past we could rightly claim that the majority of devices were too underpowered and under resourced with too little bandwidth to adopt the kinds of technologies that those pencil-necked IT guys with the skinny black ties and thick glasses used. They did their thing on the Enterprise side; building all sorts of database systems for sales and order tracking, marketing, human resources and all the rest. We did the real work of the company, PRODUCTION.
But those times are pretty much over. Our old workhorse 8-bit processors are obsolete and every year fewer and fewer silicon manufacturers are making them. The new processors are not only cheaper, they’re faster with onboard USB, Ethernet and CAN. I used to look at how many bytes of RAM a processor had and now I look at how many kilobytes or megabytes. That was unheard of just a few years ago. I used to look at a processor to see if it had Ethernet. Now I look to see how many Ethernet MACs it has, if it has an embedded Ethernet switch and even if it has its own PHY.
With all these power and data volumes growing exponentially year after year, the demand for more and more connection to Enterprise systems, more archiving of all that data, faster, and easier connection to MRP, ERP or SAP type IT type systems, we’re being dragged into the world of Objects, Entities, Relationships, and yes, Information Modeling. I admit that I was kicking and screaming about all this until I learned a little more about it. Now I marvel at the power it’s bringing to our work and that’s what I’d like to focus on in this article.
Capturing the massive amounts of data that we have today, securing it, moving it, storing it and analyzing it is now a reality for those of us trying to architect manufacturing systems. And we can’t accomplish that effectively without better mechanisms for organizing all that data. The flat file systems that PLCs have used in the past just aren’t adequate for today’s data explosion. It’s time we adopt the technologies and practices of the people that have been doing it for all these years - our friends over in the IT department. Data growing exponentially without a structure that makes it useable is an important resource that, with the right structure, could provide more efficiency and productivity, improve quality and even lower manufacturing costs. That possibility is too important to ignore.
A confusing aspect of all this is that there are Information Models and Data Models. Many designers don’t really understand the difference. An Information Model is a conceptual representation of a system devoid of any implementation details. It provides a model for designers and operators to study at the system level. A Data Model is a particular implementation of some or all of the components of the Information Model. It contains the specific implementation details that implementers require. In this article we’re only discussing Information Modeling.
An Information Model is nothing more than a logical representation applied to a physical process. An Information Model can represent something as tiny as a screw, a component of a process like a pump or something as complex and large as an entire Filling machine. The Information Model is simply a structure that defines the component devoid of any information on how process variables or meta-data within that structure can be accessed.
The first thing you do when creating an Information Model is to decide what is of interest and what isn’t. The Information Model for a pump might only contain the color, case style, manufacturer part number and purchase data if your Information Model is designed for asset tracking. It might contain none of those items if your Information Model is more process oriented. A process Information Model for that same pump might contain the current RPMs, the operating hours and the gallons per minute. Or, for a more comprehensive model, it could contain both.
Once you pick those items of interest (entities in database lingo) and you define their specific characteristics, you set up the relationships between those items. Our Filling machine has all kinds of devices - valves, pumps, motors, controllers and sensors, which we can call Objects in the model. Each of these Objects are modeled by more specialized objects. A Motor Drive Object can consist of a Motor Object and a Drive Object, for example. And those Objects can be modeled by other, more specialized Objects. As you do this, a hierarchy of Objects is developed that forms the Information Model for the system.
You can get as complex or as straightforward as you’d like. The Information Model has infinite flexibility to describe your process in whatever way serves you best. When complete you can document your process using a standard language and symbols that convey to everyone exactly what each entity is and what relationship exists between those entities.
But what have we really done? Your Information Model is only that, your Information Model. You may have modeled a pump with the characteristics speed and RPM. Someone else might have used a pump model that includes the current flow rate. The RPMs might be an integer value in one system and a float in another. Since you’ve both modeled the pump differently there are no savings in labor or productivity for either one of your customers. You may have given them a model using some open standard but they still have to incorporate your proprietary characterizations of the Objects in the model. That’s actually not much better than what we have with current day Programmable Controllers.
On top of all that we haven’t even begun to talk about common Transports, Data Encoding and access to the data contained in the Information Model. It’s one thing to define a nice Information Model for your device, your machine or production line but if there isn’t any way to easily access it using that model, it really isn’t helpful to an implementer. That problem is exactly what’s being addressed by a number of industry groups and will be the subject for the next newsletter.