Many articles on the web talk about integrating robots, machine vision, IIoT solutions, etc. If you are dealing with cobots, it makes the first item very easy. The second one is a little more troublesome because sometimes the physical location of these cameras is highly inconvenient, and the protocols used to ship many frames per second of very high-resolution photos are quite arcane to the IT specialist. As for that third item, well, much of the physical layer in IIoT is standard stuff, even though a modern fabricating shop is a noisy place, electrically speaking.
Front to back, back to front
When it is time for a new initiative, it is best to involve IT early. Let’s say you are about to embark on a project of scanning materials as they come in, and either a) making tubs or carts that will follow each part around the shop, or b) marking and numbering the materials directly, as perhaps done for a defense contractor or aerospace firm.
That’s a big project. It touches many departments. It assumes pervasive connectivity to the network. You have a lot of data going across different parts of the network. One of the necessary elements is in-line inspection of every part in two distinct locations—pre-weld and post-finish. Hmm. This job continues to grow the more we think about it.
This is where the natural differences come into play. IT staff looks at the world and tries to save we mortals from the intricacies of dealing with data, including storing all of it. We try to look at the world as we would our normal daily work. We follow our jobs from the beginning to the end, and they start all the way downstream and work their way back up. They follow it forward too with the shop managers, to find dependencies.
The first thing to do is to note all the physical locations and reasons for data being generated and captured. To the shop floor manager, it looks like the line of making a product, and might look like this: shipping and receiving > materials > laser automation > cutting > bending > inspection 1 > joining > finishing > inspection 2 > packing > palletizing > shipping and receiving. We probably left out a couple of things but this is the general idea. Production managers look at a linear process like this (let’s face it, it’s not really linear, but for argument’s sake it is here) and they can see it happen in their mind’s eye.
Given all the touchpoints in this project (most of the shop floor, and necessarily the office too), IT might look at this and say, “Before we even start talking about this implementation, let’s talk about data.” And they would be well advised to do so. Even if you already have one of those umbrella-type machine/shop management software suites, the amount of data that passes through such a system is a drop in the bucket of zeros and ones compared to the flood of data that can come from an inspection application (or two). Maybe you need 24 frames per second of 8,000 x 6,000 pixels. In raw form, you will generate 480 MB per second, 28.8 GB per minute, and 1.728 TB per hour going full-bore. Compression may save you in the end, but that is the size of the potential data debt. Never underestimate the need to build an infrastructure stout enough to throw graphical content around.
For such a project to be successful, the shop managers must own the directorship of the process, to keep it linear where it’s linear, to keep it non-linear where it’s non-linear. They are the people who know what processes must happen, what business goals must be accomplished, and what the contract calls for. They need to run through the entire project from start to finish with the IT staff.
On the other side of the table, the IT staff must understand the business and technical needs of the project, but they must start at the other end of the project—start at the end of the data stream and work their way upstream. Once they have digested the scope of the project (which they may have helped to develop from a data perspective), they can be reasonably sure of what kind of a system they must build to accommodate the new initiative.
Because the link to the cloud may not be fast enough, and because the government security protocols won’t allow anything but an on-site server, your IT team will be looking for servers and perhaps even storage farms to handle the onslaught of data.
Standard consulting practice is this: Do a needs analysis, find the application that fits it best, find the operating system it runs on, find the server and associated hardware that runs that OS, and install it. The only snag is now IT has to do the same thing with the network itself, because it has as much to do with the speed and capability of the system as any piece of hardware or software.
We’ll look at that in Part II next month, and we’ll have a checklist of good questions to ask.