What is the meaning of an event? An event informs us when something important occurred, and what that “something” is. In a factory, this can be as simple as the completion of an operation, or a change in status of some equipment. The importance of the fundamental combination of “when” and “what” can be forgotten. It only becomes apparent much later that important data is missing and that questions cannot be answered because the data does not support it. Part of the drive towards Industry 4.0 is taking smart automated decisions based on what is happening in the factory. Our data must be able to support this.
There are an infinite number of things we might eventually want to do with data we collect from the shop floor. We could be planning to feed an analytics engine in the cloud, create a performance dashboard, deliver materials to the line, verify materials, or capture traceability data. Data might be collected and processed through many steps. However, as we look back towards the actual point of primary data collection, the way we can collect the data must be defined, and with OML we not only define it, we also fully standardize it.
It does not make sense to collect data in many different ways. Not only does this create a huge amount of work to implement, but it also duplicates information, making it difficult for applications to understand the data. But we all know it can and does happen; we find equipment providing special files, extra “add on” interfaces, and so forth. The reason this can happen, is because instinctively we tend to talk about collecting data in a way we believe fits directly with what we are planning to do with it, at that particular moment in time. We have a project, it needs data and we have some pressure to deliver. Often times, the project specification quickly gets translated into the data collection needs and specifications at that moment in time. The data interface is extended, often as part of the same project. Of course this is repeated again for the next project, and hence the data interface is again changed suit.
A simple example, which although rather extreme, could illustrates the point. A customer would like to have a shift based performance report, provided at the end of each shift, that will include productivity levels and output target achievement. So the plan is for the equipment in the line to now collect the data exactly as required, as a shift report, and make a data interface to provide such a report at the end of each shift. However, although the data interface “works”, it now obviously only works for this one type of report….. Maybe with some effort, for some similar reports. If we want to use it to show the live equipment status, it is impossible to use, as the data does not exist to support a live status. Therefore, the data interface needs to be changed again should the customer require live status.
The answer is to collect data in one simple and efficient way that will still provide the details we need. We can achieve this by using events, and then use these events to feed into higher level service tiers, which in turn can provide exactly what service users need. So in our above example, a “reporting service” could easily provide a suite of different reports. If another application would like to show a live status of the shop-floor, it is easy to do, and most importantly, it can use exactly the same event-driven data as the shift report. They share the same event driven basis. The “Events Processor” component takes responsibility for understanding events and translating them into higher level report for example. A well architected system will likely share events processing logic across different applications and services. Companies will offer processing or adaptors for doing common tasks based on standards such as OML. For example, there are OML SDKs which will easily populate different types of database for any OML event. A developer simply needs to specify a data source, and connect to OML events.
Events also have other benefits. Listening for when things happen, rather than constantly asking “has something happened” is more efficient and a less complex pattern. In the software world it lends itself to what we call an asynchronous design, where components are loosely coupled without a strong dependency between them. Events also provide a way to represent any period of production in the factory, in the past, in the future, real or virtual. A sequence of events can easily be used for simulating future production for example, or testing a production system in advance. A stream of events from the past could be used for analysis which we did not think of at the time, but we can easily revisit. An event driven standard like OML considers events not only a core part of the standard, but “the standard”. If you focus on collecting your factory data using events, you will have the flexible basis to support your needs, not only the ones you think of today but also ones we dream of for the future.
Thanks for reading!
Dan Bailey
