Open Architecture "Use Cases" - the Next Frontier | Automation.com

Open Architecture "Use Cases" - the Next Frontier

January 232012
Open Architecture "Use Cases" - the Next Frontier
January 2012
 
By Bill Lydon, Editor
 
The next major frontier in the evolution of open architecture is the development of application standards built around Use Cases to increase automation productivity and efficiency. 
 
Currently the best example of this is the packaging machine standards from the Packaging Workgroup (OPW), which is part of the OMAC (Organization for Machine and Automation Control). These types of standards follow the principals of structured design methods to improve quality and lower labor hours required for programming, configuration, commissioning, startup, interface cost, and maintenance. The software industry has learned the value of employing Use Cases and structured design to significantly improve application reliability, modifiability, reusability, and maintainability. Studies of software maintainers have shown that approximately 50% of their time is spent in the process of understanding the code that they are to maintain. Standards based on structured design significantly reduce the amount of unique programming required.
 
In software engineering, Use Cases define an application challenge and are the focal point for creating high level structured designs used to build solutions. These solutions solve the stakeholder’s goals of maximizing interoperability, code reuse, quality, and efficiency.   A Use Case focuses on the relationship between systems, operators, communications, and the overall process that needs to be performed.
 
Key Concepts
 
When applying the Use Case approach, the control and automation challenge is broken into a hierarchical structure of sub problems, functions, and data/information transactions, initially ignoring application specifics like control hardware and communications protocols.
 
Abstraction
Data abstraction is an important concept for focusing on the operations of data, not on the implementation of the operations. This functional abstraction separates purpose of a module from its implementation. When these are understood, functional specifications are created for each software module before they are written.
 
Information Hiding
Details are hidden within software modules since they are the “how” that is used to implement the desired control and automaton inputs and outputs.
 
Actors
A Use Case defines the interactions between external actors and the goals of the system under consideration. Actors make decisions based on logic. An actor might be a person, a company or organization, a computer program, PLC, PAC, DCS, or a computer system (hardware, software, or both.) A person using a system is represented as an actor and their roles become part of the Use Case.
 
This approach draws on ISA-88 and other standards rather than reinventing redundant logic, framework, and concepts.
 
Why is this level of standardization important?
 
The complexity of control, automation and interaction with enterprise systems including, quality, production, asset management, and logistics are requiring much more sophisticated systems. This has created the need in many companies to have a great deal of custom control, automation, and business software to make systems work together. These custom approaches are expensive to create and maintain.  Standardization is also important for ease of maintenance, even for people that wrote the application since their own code can look unfamiliar to them in a few months.
 
There are many details that should be understood and handled in a good functional design. Questions/factors that need to be considered include:
 
  • What is the input data?
  • What data is valid & what data is invalid?
  • What error detection & error messages are required?
  • What assumptions are possible?
  • What is the form of the output(s)?
  • What documentation is necessary?
  • Fail-Safe Logic (May be more labor than the core application)
  • Extensive testing of the logic.
A standardized approach can deal with creating the logic to handle all these questions.
 
Packaging Workgroup (OPW)
 
The Packaging Workgroup (OPW) provides a great example for others to follow. Their goal is to maximize the business value of packaging machinery by improving automation guidelines and standards.   The outcomes are improved flexibility, improved capability, and reduced system integration costs. To attain this goal they work with automation suppliers, OEMs, and trade groups worldwide to encourage their support of the "Connect-and-Pack" standards. The Connect-and-Pack guidelines and standards make packaging operations more effective by simplifying customization and integration, which enables world class packaging operations. When implemented, packaging companies and their partners gain a competitive advantage. These are the organization’s sup-groups:
 
  • PackAdvantage - Identifies and communicates to the packaging industry the benefits/results of using "Connect and Pack" guidelines for packaging automation systems
  • PackConnect - Defines the control architecture platforms and connectivity requirements for packaging automation systems
  • PackLearn - Promotes awareness of Group initiatives by defining and developing programs to meet the educational and training needs of the industry
  • PackML - Develops naming convention guidelines for communications between production machinery within the packaging industry
  • PackSoft - Develops guidelines for machinery programming languages to ease learning, support transportability of software across platforms, and allow continuing innovation
What other Use Cases?
 
The OMAC packaging standards have taken time to develop but this is always true with pioneers and leadership companies that are always first to adopt. The question is what other common control and automation Use Cases are there that would benefit industry from this level of standardization? This can only happen when groups of users decide to take the bull by the horns and make it happen. The core idea is a standardized approach that is far superior to everyone “reinventing” the same basic solution over and over again.
 
This is not a task for automation vendors but for users to develop and reap the benefits.
 
Share your comments and ideas by using the “Feedback” link below.
Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now

MORE ARTICLES

VIEW ALL

RELATED