We are all familiar with automatically collecting data from equipment on the manufacturing shop floor. Data collection has rapidly expanded in the last two decades. The advances in software and hardware, and the demand to collect more data has meant a growth in both variety and volume. It is relatively straight forward to visualize the concept of data collection. Many of us likely use software solutions today, where data is being collected and utilized for many different purposes, whether that is a dashboard, a big screen above a line, loading data into a BI analytics platform, compliance archives, a production report, or tracking work order progress. Any equipment vendor will also know the expectation to provide interfaces to allow data collection from equipment. This is not to say collecting data is easy or trivial to implement (I am sure any engineering team would agree!), it has challenges, such as low latency performance, ever increasing volumes of data, reliability and security. Ensuring data is normalized is important.
ODB++Manufacturing (ODB++M) makes data collection from equipment much easier, but in this blog I want to also turn our focus towards another side of ODB++M, where the standard is not only used for data collection, but also for control and automation. In other words, using ODB++M to carry out actions automatically based on feedback, working in two directions, hence the title “Closing the Loop”. In many ways the control aspect is the more powerful part of ODB++M, taking solutions to the next level.
Let’s go back a few years to when the Industry 4.0 initiative was defined and we all started to focus on what it means in practice to build smarter factories. We learnt the key focus proposed by Industry 4.0, was automating production processes, self-monitoring these processes, diagnosing issues and taking actions and decisions, all without the need for human intervention. In other words Industry 4.0 clearly demands end-to-end “closed loop” system design. A “closed loop” system design brings in a new set of challenges, but the good news is ODB++M can help meet these challenges.
If we look at a system focusing on collecting data, even if the system were to collect every piece of data in a factory, the fact remains no decision or action will be made automatically by data collection alone. What we have is an “open loop” system, working in one direction and it has no ability to take a decision by itself. Any potential actions will require at least one human to intervene, review, decide what to do next, how to do it, when to do it, and often involve more humans. The system is collecting data, then perhaps analyzing the data and displaying it, but it is still not “closing the loop” automatically.
The human intervention needed with open loop systems can rapidly become a bottleneck. There might be huge volumes of data, but manual improvements are not actioned, or delayed actions take place, then having a reduced or even negative impact. As a side effect, those key decisions still needing our human judgement can lose focus. Although data presentation, visualizations, and user experience is ever improving, it is still needing our attention and time. Humans need to focus on the higher level decisions. We have all stories of production problems, in which a software application was apparently displaying something very important, but nobody noticed, perhaps nobody was even looking because they were busy, and the action could not be taken, or was delayed. The question now asked is can software systems decide and take the right actions by themselves next time? If not, then why not, what are the challenges to automate?
By “closing the loop” we mean taking automatic corrective action based on feedback, but what does this really mean to implement? A closed loop process has to be built into the core design of software systems. The process needs to be repeatable and automatic, always comparing the output status or results, with a set target or performance level. The term “closed loop control” was traditionally seen as a low level function, something we used to think of automation teams handling using PLCs and so forth. The drive towards Industry 4.0 and next-generation smart factories with “lights out production”, means closed loop control must be implemente, not only at the lower level but also within all the higher level MES and Shopfloor management solutions.
Closed loop automation must be integrated across all levels. This is not to suggest an MES system will take direct control of a robot head! This will always be assigned to the low level controller responsibility. However, it does mean that the MES system will take a higher level decision to automatically change the current instructions for a robot immediately, based on data it is receiving from many other areas of the factory, completely automatically and with no human intervention required, and it will be able to do this 24-7.
Siemens, through listening to the ODB++M community and working with our partners, has understood from the beginning that data collection is only part of a good standard, and we must equally strive towards using ODB++M for automating close loop control within factories. Equipment vendors are supporting ever more control functions, and manufacturers and solution providers are seeing ever more possibilities to automate and control. The ability to really develop and support “closed loop” automation scenarios is continually expanding as part of the ODB++M standard. Under the stewardship of Siemens these improvements quickly become part of the standard.
Let’s look at some examples of “closing the loop” with ODB++M. Material management is critical in any modern factory, but material is moving under the management of many different software systems and this is a challenge. Using ODB++M, factories are now able to keep material fully synchronized between equipment level software and the core MES and ERP systems using the ODB++M material integration support. If material is used in production, immediately this consumption can be fed back into a master database, and in turn this can be supplied to any other machine software at the next time material is scanned at the machine. There is no manual or human intervention, extra scanning required and the potential for mistakes is eliminated. This provides further closed loop automation opportunities when material is being tracked precisely, ranging from JIT delivery to smart inventory management.
Over the last year we have seen ODB++ increasingly used in the automated marking of products, for example laser marking being controlled automatically from higher level systems. The automatic control to stop production, or skip boards based on feedback from other machines is also something we now see being controlled in a standard way using ODB++M.
The use of AGVs and robotic handling, has provided the ability to connect equipment together in many combinations, without physical conveyor systems because it is now only a case of programming the AGV in software. This means the route products can take on a factory floor is ever more flexible, and more dynamic, and at the same time less directly supervised by humans. This means an increasing demand for automatic checks to prevent products from entering the wrong process. ODB++M supports this this type of closed loop control, first by providing the data to track products through each process in real time, and then by providing the control via an input conveyor or preventing the equipment to start work if the next process is not valid.
These are just a few of the closed loop automation examples that can be achieved today using ODB++M, but we know there will be many more to come, every month new ideas and directions emerge in discussions. This is one of the most exciting areas of ODB++M, where we see the core principles outlined in initiatives such as Industry 4.0 really burst into reality.
Want to learn more? Check out the resources on the ODB++M website>>
