One of the key tools that lets standards bodies create more precise standards is the Unified Modeling Language.
UML, itself an ISO standard from the International Organization for Standardization, has been used to create standards such as the Instrumentation, Systems and Automation Society’s ISA88 and ISA95 standards, as well as the PackML standard created by the Open Modular Architecture Control (OMAC) Users Group. Using UML to describe facets of specifications has done a lot to eliminate a vexing issue for volunteers trying to come to a consensus on complex issues—helping organizations finish standards in a timely fashion. That’s in part because UML’s models provide precision and eliminate the back-and-forth questions over the meaning of terms.
“UML provides a standard way for describing and defining complex systems. It represents in pictures what it would take several sentences to describe. With diagrams, you can concisely say in exquisite detail what you’re trying to do,” says Dennis Brandl, senior consultant at BR&L Consulting Inc., of Cary, N.C., who has played key roles on both the ISA95 and ISA88 standards committees.
Broad usage
UML has played a major role in the development of many standards. It’s only been about a decade since the many object-oriented modeling techniques were brought together under the auspices of the Object Management Group, so its impact doesn’t go back too far. But standards bodies were early adopters, once UML became available. “Parts 2, 3 and 4 of ISA88 use UML modeling. It wasn’t around for the first part. Part 4 uses formal models that contain a level of detail not provided in the other parts,” Brandl says.
Though the ISA88 developers jumped on the bandwagon early on, their initial efforts came close to being categorized under “more pain than it’s worth.” As with many jobs done with computers, getting started wasn’t always the easiest of jobs. “It’s fair to say it took longer to develop the standard because we used UML. There is pain up front, but it pays off in the end,” Brandl says.
If any group is aware that adopting a single approach that has been agreed to by a number of people is difficult, it’s standards bodies. Successes in many of the initial UML-based development projects led to widespread usage in this influential community. Some of these projects extend into areas that weren’t considered when UML was created.
However, that doesn’t mean that the language can’t be stretched. “Some of the macro states in PackML were a little difficult to describe in formal UML, so we took some liberties,” says Rick Morse, software business manager at vendor Rockwell Automation Inc., in Mayfield Heights, Ohio. “Some of the work in ISA88.5 takes things further with macro states, breaking the confines of what UML offers.”
He notes that when rules are stretched or broken, UML tools offer cross-checking. “Cross-checking between formats works like a good compiler check. The tools give us a sense of whether we’ve forgotten anything or left out large sections,” Morse says.
E pluribus unum
In standards bodies, as in many aspects of the business world, making it simple to keep everyone on the same page is a critical factor for successfully creating an end document. UML’s ability to relay explicit information eliminates confusion. But observers note that its benefits don’t extend further than that.
“UML eliminates ambiguities. It’s done so much to show a better way, as it provided a commonly understood unifying tool,” Morse says. “It’s not a silver bullet that solves any work that needs to be done, but it eliminates the time spent tripping over the way we communicate.”
Avoiding the time-consuming aspect of clarifying communication is a huge benefit, particularly when disparate groups are involved in the development of a standard. The volunteers who create standards come from many different fields, which helps bring richness to the end document. Their broad range of expertise correlates to a wide range of terminology and various levels of understanding in different fields. The benefit of the clear visual representations inherent in UML presentations is huge in this environment.
“A lot of people working on standards are not software engineers. They are subject matter specialists. Often, there are people looking at aspects that they don’t understand,” Brandl says.
越来越多的这些主题专家是疯狂的ated on different continents. That brings up yet another type of incompatibility. Language barriers are dramatically reduced when graphical representations are used. “The biggest benefit is that it provides a consistent way of communicating across a very divergent group, which is especially important when you’re working with an international group,” Morse says.
Who needs it?
Though UML was important in the development of many standards used in industrial automation, it’s not mandatory for users of these standards to learn about the modeling language. “If you buy products built on the ISA88 standard, you don’t need models. They are more for the developers,” Brandl says.
When companies are using the standards to develop their products, there is little incentive to employ the technology used to build the standard. These documents generally describe approaches that are more appropriate for production level tasks.
“Most of the output that becomes productized from ISA88, ISA95 and PackML is non-UML driven. It’s more driven by state machines and timing diagrams described in the standards,” Morse says. However, most equipment makers employ UML’s concepts in their products. Some of them maintain terms from UML documentation, leveraging the standardization to assure that all parties use identical terminology.
“Our Equipment Operations Module or Enterprise Integrator products use standard terminology like Segment Response, or Production RuleID. The same goes with ISA88 and our InBatch product where we use terminology like Formula, Procedure and phases,” says Yves Dufort, director of manufacturing industry business development at Wonderware, an automation software provider based in Lake Forest, Calif.
In some instances, product developers can employ UML in the factory to create models for the materials they’re putting together to make their end product.
“Several large companies have taken models to build integrated data models for their recipes that will be run on systems with controllers from, say, Siemens or Rockwell,” Brandl says. “If they build integrated models based on UML models, UML gets them quite far. They can probably save 50 percent vs. building their own integrated data models.”
Eliminating ambiguity by using common terminology brings major benefits in all aspects of product development, whether it’s for creating formulas or programming equipment. When developers don’t waste time deciphering terms, they can focus on the job at hand. “Time-to-value is the greatest benefit from a customer standpoint, since everybody uses the same definition for the state data,” Dufort says.
State models
Making sure everyone is on the same page at all times is one of the keys of many standards created using UML. Models remain the tool of choice, providing visual elements that eliminate the confusion that often occurred before models replaced verbal descriptions. Because the jobs they address can be vastly different, these models aren’t universal. Standards focus on these variations, providing different models and tools for the various aspects of production that they address. For example, ISA88 breaks production into two key categories.
“ISA88 guidelines define two models. One is procedural, which says how a product is made—the recipe. The other is equipment models that describe equipment and how it operates. Within the processes are the capabilities of each unit,” says Rob Purvey, senior consultant at vendor Siemens Energy & Automation Inc., in Spring House, Pa.
These state models have many layers. At the lowest are control modules, typically devices such as valves and motors that just turn on or off. They’re grouped as equipment models, with states such as run, hold, abort and start.
“ISA88 defines entire models around these states. One of the key benefits is that when end-users have conversations, they’re speaking the same language. They can describe an equipment model and say, ‘This is what we want in the various states,’ ” Purvey observes.
These models also make programs much more portable. Because jobs are created by linking blocks together, segments of these linked building blocks are easy to move from one machine to another. That’s a boon for programmers, who often create variations of a basic operation. “Before ISA88, if you programmed a giant sequence for product one, then you went to a similar second product, you still had to do another giant sequence. The recipe maker had to be involved with both. With ISA88, there are clear separations between controllers and recipes,” says Todd Stauffer, product manager at Siemens Energy & Automation.
Another benefit is that these models can be altered a bit when they don’t meet specific needs. That’s not unusual in the complex world of automation equipment, in which equipment from various vendors is routinely linked so that one-of-a-kind jobs can be performed. Many production tools give users a high level of freedom.
“Our technology allows customers to reconfigure to any state model at runtime. So if they use variations of the standard PackML state model, we can use them as well,” says Wonderware’s Dufort.
Before any of these equipment programs are run, users will typically do everything they can to eliminate errors. Modeling makes that much simpler. It’s pretty straightforward to create and run model-based simulations. “You can create simulations to ensure that the equipment does what you want it to do. There will usually be things you miss. Doing process simulations lets you catch problems,” Purvey says.
Recipe for success
Setting up equipment is the big step, but little can occur until managers create formulas and recipes for the products they’re going to make. Here again, the state models within standards simplify the job of determining how materials will be put together.
A critical aspect of these materials is how their distribution and treatment is handled by equipment on the shop floor. One important benefit of standards is that they make it more likely that the people who know how to prepare materials to create an end product can also set up the equipment that will process these materials.
“Procedural models define how you make products. With them, the recipe guys don’t have to know how to program equipment. They can build the equipment operations with Lego blocks so they don’t need to learn how to program,” Purvey says.
This capability also makes it simpler to move these recipes from one facility to another. That’s a big benefit in an era when commodity prices and monetary exchange values change quickly. Being able to move production to another site in order to take advantage of these changes can provide a nice boost in bottom-line profits.
“随着技术的发展,你想能upgrade a plant to the latest and greatest without altering your recipes. When you use the processes to define the recipe, you’re not tied to a site or the equipment at a site. Transporting the formula to another site becomes easier, because people are using the same format,” says Siemens’ Stauffer.
UML, itself an ISO standard from the International Organization for Standardization, has been used to create standards such as the Instrumentation, Systems and Automation Society’s ISA88 and ISA95 standards, as well as the PackML standard created by the Open Modular Architecture Control (OMAC) Users Group. Using UML to describe facets of specifications has done a lot to eliminate a vexing issue for volunteers trying to come to a consensus on complex issues—helping organizations finish standards in a timely fashion. That’s in part because UML’s models provide precision and eliminate the back-and-forth questions over the meaning of terms.
“UML provides a standard way for describing and defining complex systems. It represents in pictures what it would take several sentences to describe. With diagrams, you can concisely say in exquisite detail what you’re trying to do,” says Dennis Brandl, senior consultant at BR&L Consulting Inc., of Cary, N.C., who has played key roles on both the ISA95 and ISA88 standards committees.
Broad usage
UML has played a major role in the development of many standards. It’s only been about a decade since the many object-oriented modeling techniques were brought together under the auspices of the Object Management Group, so its impact doesn’t go back too far. But standards bodies were early adopters, once UML became available. “Parts 2, 3 and 4 of ISA88 use UML modeling. It wasn’t around for the first part. Part 4 uses formal models that contain a level of detail not provided in the other parts,” Brandl says.
Though the ISA88 developers jumped on the bandwagon early on, their initial efforts came close to being categorized under “more pain than it’s worth.” As with many jobs done with computers, getting started wasn’t always the easiest of jobs. “It’s fair to say it took longer to develop the standard because we used UML. There is pain up front, but it pays off in the end,” Brandl says.
If any group is aware that adopting a single approach that has been agreed to by a number of people is difficult, it’s standards bodies. Successes in many of the initial UML-based development projects led to widespread usage in this influential community. Some of these projects extend into areas that weren’t considered when UML was created.
However, that doesn’t mean that the language can’t be stretched. “Some of the macro states in PackML were a little difficult to describe in formal UML, so we took some liberties,” says Rick Morse, software business manager at vendor Rockwell Automation Inc., in Mayfield Heights, Ohio. “Some of the work in ISA88.5 takes things further with macro states, breaking the confines of what UML offers.”
He notes that when rules are stretched or broken, UML tools offer cross-checking. “Cross-checking between formats works like a good compiler check. The tools give us a sense of whether we’ve forgotten anything or left out large sections,” Morse says.
E pluribus unum
In standards bodies, as in many aspects of the business world, making it simple to keep everyone on the same page is a critical factor for successfully creating an end document. UML’s ability to relay explicit information eliminates confusion. But observers note that its benefits don’t extend further than that.
“UML eliminates ambiguities. It’s done so much to show a better way, as it provided a commonly understood unifying tool,” Morse says. “It’s not a silver bullet that solves any work that needs to be done, but it eliminates the time spent tripping over the way we communicate.”
Avoiding the time-consuming aspect of clarifying communication is a huge benefit, particularly when disparate groups are involved in the development of a standard. The volunteers who create standards come from many different fields, which helps bring richness to the end document. Their broad range of expertise correlates to a wide range of terminology and various levels of understanding in different fields. The benefit of the clear visual representations inherent in UML presentations is huge in this environment.
“A lot of people working on standards are not software engineers. They are subject matter specialists. Often, there are people looking at aspects that they don’t understand,” Brandl says.
越来越多的这些主题专家是疯狂的ated on different continents. That brings up yet another type of incompatibility. Language barriers are dramatically reduced when graphical representations are used. “The biggest benefit is that it provides a consistent way of communicating across a very divergent group, which is especially important when you’re working with an international group,” Morse says.
Who needs it?
Though UML was important in the development of many standards used in industrial automation, it’s not mandatory for users of these standards to learn about the modeling language. “If you buy products built on the ISA88 standard, you don’t need models. They are more for the developers,” Brandl says.
When companies are using the standards to develop their products, there is little incentive to employ the technology used to build the standard. These documents generally describe approaches that are more appropriate for production level tasks.
“Most of the output that becomes productized from ISA88, ISA95 and PackML is non-UML driven. It’s more driven by state machines and timing diagrams described in the standards,” Morse says. However, most equipment makers employ UML’s concepts in their products. Some of them maintain terms from UML documentation, leveraging the standardization to assure that all parties use identical terminology.
“Our Equipment Operations Module or Enterprise Integrator products use standard terminology like Segment Response, or Production RuleID. The same goes with ISA88 and our InBatch product where we use terminology like Formula, Procedure and phases,” says Yves Dufort, director of manufacturing industry business development at Wonderware, an automation software provider based in Lake Forest, Calif.
In some instances, product developers can employ UML in the factory to create models for the materials they’re putting together to make their end product.
“Several large companies have taken models to build integrated data models for their recipes that will be run on systems with controllers from, say, Siemens or Rockwell,” Brandl says. “If they build integrated models based on UML models, UML gets them quite far. They can probably save 50 percent vs. building their own integrated data models.”
Eliminating ambiguity by using common terminology brings major benefits in all aspects of product development, whether it’s for creating formulas or programming equipment. When developers don’t waste time deciphering terms, they can focus on the job at hand. “Time-to-value is the greatest benefit from a customer standpoint, since everybody uses the same definition for the state data,” Dufort says.
State models
Making sure everyone is on the same page at all times is one of the keys of many standards created using UML. Models remain the tool of choice, providing visual elements that eliminate the confusion that often occurred before models replaced verbal descriptions. Because the jobs they address can be vastly different, these models aren’t universal. Standards focus on these variations, providing different models and tools for the various aspects of production that they address. For example, ISA88 breaks production into two key categories.
“ISA88 guidelines define two models. One is procedural, which says how a product is made—the recipe. The other is equipment models that describe equipment and how it operates. Within the processes are the capabilities of each unit,” says Rob Purvey, senior consultant at vendor Siemens Energy & Automation Inc., in Spring House, Pa.
These state models have many layers. At the lowest are control modules, typically devices such as valves and motors that just turn on or off. They’re grouped as equipment models, with states such as run, hold, abort and start.
“ISA88 defines entire models around these states. One of the key benefits is that when end-users have conversations, they’re speaking the same language. They can describe an equipment model and say, ‘This is what we want in the various states,’ ” Purvey observes.
These models also make programs much more portable. Because jobs are created by linking blocks together, segments of these linked building blocks are easy to move from one machine to another. That’s a boon for programmers, who often create variations of a basic operation. “Before ISA88, if you programmed a giant sequence for product one, then you went to a similar second product, you still had to do another giant sequence. The recipe maker had to be involved with both. With ISA88, there are clear separations between controllers and recipes,” says Todd Stauffer, product manager at Siemens Energy & Automation.
Another benefit is that these models can be altered a bit when they don’t meet specific needs. That’s not unusual in the complex world of automation equipment, in which equipment from various vendors is routinely linked so that one-of-a-kind jobs can be performed. Many production tools give users a high level of freedom.
“Our technology allows customers to reconfigure to any state model at runtime. So if they use variations of the standard PackML state model, we can use them as well,” says Wonderware’s Dufort.
Before any of these equipment programs are run, users will typically do everything they can to eliminate errors. Modeling makes that much simpler. It’s pretty straightforward to create and run model-based simulations. “You can create simulations to ensure that the equipment does what you want it to do. There will usually be things you miss. Doing process simulations lets you catch problems,” Purvey says.
Recipe for success
Setting up equipment is the big step, but little can occur until managers create formulas and recipes for the products they’re going to make. Here again, the state models within standards simplify the job of determining how materials will be put together.
A critical aspect of these materials is how their distribution and treatment is handled by equipment on the shop floor. One important benefit of standards is that they make it more likely that the people who know how to prepare materials to create an end product can also set up the equipment that will process these materials.
“Procedural models define how you make products. With them, the recipe guys don’t have to know how to program equipment. They can build the equipment operations with Lego blocks so they don’t need to learn how to program,” Purvey says.
This capability also makes it simpler to move these recipes from one facility to another. That’s a big benefit in an era when commodity prices and monetary exchange values change quickly. Being able to move production to another site in order to take advantage of these changes can provide a nice boost in bottom-line profits.
“随着技术的发展,你想能upgrade a plant to the latest and greatest without altering your recipes. When you use the processes to define the recipe, you’re not tied to a site or the equipment at a site. Transporting the formula to another site becomes easier, because people are using the same format,” says Siemens’ Stauffer.
![Mps035 Sm 1200x628 D[2]](https://img.automationworld.com/files/base/pmmi/all/image/2021/03/MPS035_SM_1200x628_D_2_.604a4a336bc60.png?auto=format%2Ccompress&bg=fff&fill-color=fff&fit=fill&h=146&pad=5&q=70&w=340)
