That much became clear in a recent phone conversation with Pearson engineer Peter Lawton:
* We use OMAC for two reasons. First, we believe that being OMAC compliant will eventually be an absolute requirement. End users will expect it. And second, some end users are asking for it now, certainly the large ones.
* What does OMAC do for us? We don't have to redesign our code to interface to whatever SCADA or MES system a customer may have. When we have to do that kind of code work, it carries a cost.
* One thing keeping smaller or even mid-sized end users from taking better advantage of OMAC is that specifying it can add cost. Think of the machine builders. If they're building a new machine from scratch, they can design in OMAC compliance. But adding PackML to a machine that has been long been available without it includes an engineering cost. In our case the customer doesn't bear all the cost because we're partnered with Rockwell when it comes to doing such conversions. Some of our resources and some of theirs are brought to bear. But elsewhere it's not uncommon for an OEM to charge $40,000 for an OMAC implementation on a standard piece of equipment.
* Ultimately we see OMAC-compliant machines as tools that will help end users compete. Let's face it, everybody has limited resources. If an end user has to draw up a specification as to how memory should be laid out or this is the data we want, that eats up engineering time that could be used somewhere else.
