Wonderware’s ArchestrA architecture is a great platform on which to build manufacturing automation. Why? Because it is the only platform that truly brings the power of something called “object orientation” to the plant floor. If you don’t know about object orientation, that’s OK – we’ll just tell you that it has many benefits, probably the biggest of which is the ability to re-use software at many levels.
However, the mechanics of dealing with programming objects on an individual basis, such as through the Wonderware Integrated Development Environment (IDE), can be tedious. Each object that a programmer wants to change must be “checked out” of the galaxy, modified individually, and then “checked in” again. For a few objects, this is not an issue, but for many, all the time to check out, check in, and modify objects one at a time begins to add up.
Seeing this as an opportunity to increase productivity, Flexware began working on a tool we now call the Galaxy Object Manager (GOM) back in 2006. The idea was to manage galaxy information in spreadsheets, giving us the ability to access and change many objects at once, and to upload and download those objects between the galaxy and the spreadsheets all at once. Additional features have been added along the way, and the GOM is now a very powerful productivity tool and a major competitive advantage for Flexware.
So how big is this advantage? When developing a galaxy “from scratch”, it is a modest but still worthwhile 10-20% less effort with the GOM than without. However, once you have a galaxy that you need to maintain, modify, and/or roll out to other lines or plants, the benefits jump to at least 30-50% less effort, and as much as 80% in some situations. A few thumbnail case studies will help to highlight the advantages of the GOM.
Case 1 – Many Rollouts.
Flexware was bidding a project for a customer that wanted to develop a highly custom, very feature-rich MES and performance system, and then roll it out, with some variations, to 80 lines. Although the cost of initial development was quite large, we demonstrated to them that what they really needed to be concerned about was the cost of the 80 roll outs, as even relatively small costs get very big when multiplied by 80. In this scenario, our GOM was a huge competitive advantage, enabling us to win the project, which is currently in the middle of the roll out phase. The roll out effort and cost is turning out to be even smaller than we had predicted during the bidding phase. In fact, the entire cost for services to roll out the MES to another line is less than the cost of the software licensing to do so – which is unheard of in almost any industry.
Case 2 – Changes At Startup.
Flexware had been contracted to provide the MES for a large new complex line at a major food manufacturer. The equipment and PAC controls that our MES would be interfacing to were being provided by several different vendors, all outside the U.S. Early on in the project, standards were established for naming the signals that would be communicated between the MES and the PACs. The fast track schedule prevented the automation pieces from coming together for testing prior to startup. Lo and behold, when it came time for startup, it turned out that we had followed the standards for naming the interface signals, but some of the equipment vendors had not. And those vendors were fully occupied with other issues on the customer’s site. Thus, the onus was on us to change all of our objects that referenced those signals. This was a large galaxy with a huge number of objects, and our engineers estimated it would take two days to make all the changes via the IDE (and be prone to keystroke mistakes). This would have been devastating to the commissioning schedule. Using the GOM, all the changes were completed in two hours (and with far fewer chances for mistakes), keeping this problem off the “critical path”. We have had similar cases with several other customers.
Case 3 – Fixing a Poorly Architected Galaxy.
Object orientation rewards good up-front designs with systems that are easy to enhance and change, but the reverse is also very much true – it punishes bad up-front designs with systems that are difficult or even impossible to change. When they learned of our ArchestrA expertise and our GOM, a new customer came to Flexware for help. Their galaxy, designed by a system integrator who did not thoroughly understand object oriented environments, had serious design flaws, chief among which were insufficient levels of derivation in numerous places. (If you don’t understand “insufficient levels of derivation”, it’s OK – just know that it can be a show-stopper in a galaxy.) Adding levels of derivation with the IDE is a particularly tedious procedure and involves deleting and completely re-entering many objects. With the GOM, it is nearly painless. Flexware read this customer’s galaxy into the GOM, increased the levels of derivation where needed, and downloaded the result back into his galaxy, all in less than a quarter of the time it would have taken without the GOM. That customer is now coming to Flexware for all their ArchestrA work.
Case 4 – Long Term Support.
Flexware designed a very distinctive MES system for a Fortune 100 snack food manufacturer, and rolled it out to eight plants. (Distinctive because this MES requires no routine operator interactions). The plants, of course, are not static – new ingredients, new products, and new lines occasionally get added. The GOM has enabled Flexware to make such modifications for a small fraction of what they would otherwise cost. Adding a new product can be done in 1-2 days, while a new line might take 2-3 days. These would take approximately 8 times longer without the GOM.
Case 5 – Investigating a Galaxy for Enhancement.
Flexware may have to enhance or modify a galaxy from a past project or a system not developed by Flexware. For example, trying to determine what objects would be affected by a stored procedure change. The GOM can cross reference the stored procedure name throughout the galaxy and return all affected objects/graphics. Without the GOM a user would have to change the store procedure and find what objects were broke after the fact through use or the SMC log.
Some of our competitors have of late begun playing “me too” with this idea of maintaining galaxies outside of the IDE. However, their implementations work through the galaxy dump and load utility (and were therefore easier and quicker to write), while Flexware’s GOM works through the direct galaxy programming port, called “GRAccess”. This gives Flexware’s GOM several huge advantages:
- The GOM can and does work with templates as well as instances, while programs using the galaxy dump and load work only with instances. This is a profound difference. Much of what is done when modifying galaxies is done to templates. As just one example, the GOM has a feature called “Cascade Unlock”, which unlocks selected attributes all the way down a hierarchical chain. Because this requires changing templates, it would not be possible in a dump/load-based tool.
- The GOM works with scripting, while programs using dump/load do not. Scripting is normally a very significant part of galaxy objects. A tool that does not handle it is severely crippled. For example, using the GOM and your favorite editing tool, you can in one action search all the scripting in a galaxy for certain variables, or make a mass substitution of one variable for another throughout all scripting in the galaxy. Without that ability, you would have to check out each object with scripts, open each script in each object one by one, search and replace the variable, and then check the object back in. Then repeat for all scripted objects. This could easily take 100 times as much time as with the GOM. Ouch!
- The GOM has the ability to export graphics (symbols, and instance/template graphics) into user-readable XML. This can allow, much like scripting, the ability to search or replace all of your Graphics for variables, text strings, properties, or script references.
- The format of the CSV file for a galaxy in the GOM is much easier to read and deal with than the format for dump/load, which in some cases concatenates many attributes together in a single entry.
- The GOM has the ability to cross reference an entire galaxy for specific objects by:
- Attribute values (strings, numbers)
- Script contents
- Graphic scripts (symbols on instances or templates)
- Graphics properties and values (strings, numbers)
The moral of this story is that when some other integrator tells you that “they have a galaxy productivity tool, too”, beware! Although they are both cars, an Edsel can’t really be compared to a Corvette.
