How to Break the Automation Pyramid with the Metals Service Bus
27 Aug 2019 - Research, Industry 4.0, Technology, Artificial Intelligence
The organization of systems relevant to metal production has been successfully carried out for many years on the basis of the so-called “automation pyramid”. This structure, however, reaches its limits when it comes to adopting new methods, such as Big Data, Artificial Intelligence and Machine Learning. By eliminating the strict layering of the pyramid towards a system of peers, a standard is required. The PSIbus technology closes this gap. In 10 Q&A’s you will learn, how the technology enables the smooth interaction of the various components, systems and the adaptation of new IT technologies while maintaining a holistic view on processes and data to meet the requirements of metal production.
10 Q&A’s Around the Metals Service Bus
- What is the “automation pyramid”?
- How do the layers interact with each other?
- Why is it difficult to adapt new technologies such as Artificial Intelligence (AI) to the automation pyramid?
- What challenges does the automation pyramid-approach face?
- How can a different organization of layers look like?
- How can communication between systems be unified in a “layer-free” concept?
- What is the “Service Bus”?
- What is “PSIbus”?
- How to break up the automation layers into smaller services?
- How does Service Bus differentiate to PSIbus?
1. What is the “automation pyramid”?
International automation standards like ANSI/ISA-95 organize metal production hierarchically in several layers: starting with process control (L1) at the base, followed by process automation (L2), then manufacturing execution (L3), and finally business management (L4). The layers together form the so-called “automation pyramid”.
2. How do the layers interact with each other?
Each system residing on a layer of the pyramid has evolved over the last few years, focusing especially on optimizing the respective processes of its contained layer. The systems can only interact with each other by exchanging data and control flows between adjacent layers. The descriptions of how parts of different layers interact with each other are called “interfaces” and each interface uses its own language. The language of some interfaces is expressed in a standardized way, while others use a completely unique language, spoken and understood only by two interacting parts of the automation pyramid.
3. Why is it difficult to adapt new technologies such as Artificial Intelligence (AI) to the automation pyramid?
In the quest for examples for the adaptation of AI and ML topics to the established automation pyramid, the inherent problem becomes visible. AI, and in particular its application ML, need a highly integrated view of the acquired data and its consuming processes. The data that can be considered as input for these techniques comes from various sources such as elaborated systems, but also from sensors that mainly provide raw data with a high level of detail. The combination of the data from all these sources forms the basis for what we call today “Big Data”.
Example: Big Data and Machine Learning
A working example of the combination of Big Data and Machine Learning in a production environment is the idea of predicting the quality of a finished product based on its routing through different production lines before the production begins. To achieve a prediction of significant quality, different data sources have to be taken into account:
- The aimed quality of the goods to produce;
- The current state of the equipment to be used to produce the goods (e.g. the installed rolls for the cold rolling process, maintenance cycle, etc.);
- Sequence of production steps to produce the material;
- Process parameters, such as temperatures, pressures, etc.;
- Environmental influences, like the actual weather conditions.
Based on historical data on various influencing parameters as well as the current condition of a plant and its surroundings, a prediction can be made in advance about the quality of a material to be produced. The result of the prediction influences the choice of production route in order to increase the resulting quality and minimize the number and severity of defects. This prediction mechanism needs all data listed above from different sources. The mapping of these sources to their respective layer in the automation pyramid draws an image with high distribution between all layers of the pyramid.
In order to benefit from new technologies, the algorithms require a holistic, highly integrated and unbiased view on all data created, modified and processed in the manufacturing process.
This includes the data and its sources across all layers of the automation pyramid, from Level 1 to Level 4. Applying these mechanisms by using the current infrastructure of the automation pyramid is difficult or even impossible to accomplish.
4. What challenges does the automation pyramid-approach face?
The approach of the automation pyramid with its hierarchy, strong separation of the responsibilities of the individual layer and highly specialized products serving each layer has proven itself over many years. Several shifts in the IT industry with emerging new research fields, new opportunities and production-ready software components, however, are putting this approach under pressure. The infrastructure of the automated pyramid somehow hinders the proper deployment of these new technologies.
One reason for this is the introduced hidden abstraction between the layers. Since each layer concentrates mainly on its own view of the data and the required processes on its own level, an inseparable loss of information in the interfaces between the different layers occurs.
Example: Gathering information across all levels (I)
For example, a Level 3 process to plan the routing of an order through production lines never needed to know about the average pressure of the upper support roll when performing the cold rolling process. But now this process and its supporting algorithms need this information to bring this data into relation with the choice made in similar previous situations. Or it might be reasonable to have detailed information about the order book at a Level 2 process for being able to adjust a cut to length during the continuous casting process when a quality decrease has been noticed. Cutting the strand too short with no order to fulfill it leads to unnecessary unassigned semi-finished material, while performing the cut just 50 centimeters later could have perfectly fit to an open order.
Since IoT, Big Data, Machine Learning and so on teach us how to benefit from unbiased data, the existing layering of the automation pyramid reaches its limits. The use of abstraction between the layers inherent to the interfaces hides data from the level above and below each layer - this effect even multiplies when crossing more than one layer. Information from Level 1 will most likely never have the same meaning and completeness when it reaches Level 3 due to the abstraction of interfaces and Level 2 in between. This information may not even be perceived by Level 3, since Level 2 “decides,” it is not useful to pass it on to Level 3. The same applies to the downstream direction from higher to lower levels.
Another problem that does not relate specifically to new IT areas, but to the continued use of a layering aspect, is the lack of the ability to adapt quickly to changes.
Example: Gathering information across all levels (II)
As mentioned in the above example, it may be necessary to have detailed information about upcoming orders directly in the control system of a continuous caster. By using the automation pyramid, this information must be taken from a Level 4 system and passed through a Level 3 system to be available in a Level 2 system. Building such a system may be easy at first, but how do you deal with the situation when caster-specific information has been added to the orders of Level 4? Passing from Level 4 to Level 2 always involves a change within the Level 3 system, even if the attribute is irrelevant for the processes handled by Level 3.
The use of a strict automation pyramid approach tends to result in unnecessary changes to running systems, creates dependencies on external vendors, occupies their resources, and hampers their ability to make the change.
In view of the described problems with the automation pyramid and the willingness to adapt to new areas and technologies, a different organization of the layers of the automation pyramid must be found.
5. How can a different organization of layers look like?
Different forms of organization can be found in different areas of our daily lives. Some companies have changed their organizational structure from a strict hierarchical layout to a matrix layout where each part of the company can interact with a different part without respecting the layers. Software application architectures change from layered architecture to hexagonal architectures or even complete microservices architectures.
Therefore, breaking down the layers of the automation pyramid into smaller parts, with each part communicating directly with the other, may enable new application areas. This means not only the removal of the layers themselves, but also the possibility to integrate the individual parts in a business process-oriented way. In summary, this means eliminating the horizontal aggregation layer and creating vertical integration alongside the business processes.
6. How can communication between systems be unified in a “layer-free” concept?
By changing the organization of the system participants, it is necessary to harmonize the type of communication and its semantics in order to enable the interaction of various “layer-free” pieces. Without such a standardization approach, the combination of two different parts of the new organizational structure leads to a specific implementation. If another part comes that has to deal with the already existing parts, the number of communication interfaces and thus the effort for implementation is doubled. Adding more and more parts to interact with each other will result in an explosion of required communication interfaces.
In order to address this problem of unifying communication between different parts of metal production services, PSI Metals hereby introduces the PSIbus and its extensions to a Metals Service Bus.
7. What is the “Service Bus”?
The term “bus” has been used by the IT industry for almost decades, culminating in the early 2000s and experiencing a revival around 2010. These systems were mostly developed as simple, lightweight communication frameworks, but gradually over time more and more intelligence was brought into the bus itself - until evolved into a full Enterprise Service Bus (ESB). For example, the selection of which part of the system is to be used to fulfill a certain system function was placed into the bus as a task. Thereby more and more domain knowledge went from the involved parts into the bus itself.
A further step towards complexity was to enable the business infrastructure itself to translate between different dialects of the participants. This also led to abstraction and loss of information through transformation. It turned out that these approaches to bringing intelligence into the early bus systems made them too overloaded and complex for operation. At the very end the “bus” itself was not a communication technique anymore, it became the application itself.
8. What is “PSIbus”?
PSI Metals introduces the PSIbus for the metal industry as a generic term for aggregating:
- a concept of how the different parts of a steel manufacturer’s entire IT system interact
- a protocol of how to exchange data and flows between different participants
- a ready-to-use software infrastructure, enabling the participants to communicate and collaborate
If one groups these points of the PSIbus together with its metal-specific usage, one can call this aggregation “The Metals Service Bus”.
9. How to break up the automation layers into smaller services?
The first step to breaking down the automation pyramid is to think about a different way of collaboration among the participants. By breaking down the layers into individual parts, it is by design encouraged to enable direct communication between all parts involved - the collaboration shifts from a hierarchical to a peer type. In this way, all participants are treated equally and thus have access to the same wealth of data. PSImetals as production management software (MES) is the first metal-specific user of the Metals Service Bus. By using the PSIbus as the backbone for the interaction of individual parts, the "inner" components of the MES become visible to the outside. The internal components of the MES can also be easily integrated with other PSIbus participants. This opens up the possibility of cooperation and enables valuable business-to-business communication.
Besides the ability to connect different systems and components, the “language” to be used is a key factor for the successful integration of these different parts. In order to avoid the "Babylonian language confusion", it is absolutely necessary to unify the language to be spoken - within information technology this is referred to as “protocol”. In addition to a technical platform for data and flow exchange, PSIbus also offers a uniform protocol as a standardization proposal. The protocol itself is based on a textual representation of data that is human- and machine-readable and follows the IT-wide standard JavaScript Object Notation (JSON).
In addition to the standard protocol and the interaction concept, the PSIbus also requires a software infrastructure. One of such software infrastructure components are provided by PSI Software AG, the parent company of PSI Metals, as part of the PSI Java Framework. The components are used in many industries, such as gas and oil transport monitoring systems, warehouse management and other manufacturing systems. PSI Metals uses these components by extending this bus with specific configurations tailored to the needs of steelmaking and the manufacturing process. To enable systems other than those of PSI to participate in the PSIbus, communication is based on standards such as REpresentational State Transfer (REST) and Java Message Service (JMS). This, in combination with the open protocol, makes it possible to connect almost any system to the bus with any possible programming language, environment or framework.
10. How does Service Bus differentiate to PSIbus?
In order to distinguish itself from these early bus systems, the PSIbus with its metal-specific extensions follows a strict separation of concerns. The PSIbus itself is an architectural approach to combining different parts of different systems through a unified transport mechanism and protocol – it does not bring the intelligence of the domain of how to produce steel into this infrastructure itself. In fact, it forces system participants to act as intelligent endpoints and keep the business logic on their side.
As always, this mantra has its special name in the IT industry and is in line with the proverb “Dumb pipe - smart endpoints”.
Heiko Wolf, Director PSImetals FutureLab
Heiko has been developing software for the Steel and Aluminum industries at PSI Metals for the past 12 years. As the head of the FutureLab project he gets to think about Software Architecture, continuous delivery and agile methodologies, and how all of that fits in his industry.
+49 30 2801-1863
hwolf@psi.de
