Why simulate electronics production?
Over the last year like many of us, I have missed the physical visits to our customers, meeting suppliers and partners face to face. Many of us have not been able to get close to production or even see demonstrations of equipment at trade events. I can only admire my own colleagues, and all the people around the globe working inside factories over this last year, keeping lines running and critical supply chains open.
Being detached from physical production got me thinking again about manufacturing simulation, a topic we are passionate about in Siemens, and a topic that has become increasingly important over this last year. I wanted to go back to basics, and remind myself of what we really mean when we use the term “simulation”. In my opinion this definition captures it very nicely:
“A simulation is the imitation of the operation of a real-world process or system over time”.
So an ability to imitate, an understanding of time, a system understanding or model are the ingredients we need to make a good “simulation”. How can we simulate a production or manufacturing system in our own domain? This is where ODB++M appears a good fit. ODB++M is capturing all the key physical events that occur during production, recording the time they occurred and based around a consistent model of production. ODB++M can also capture the commands and instructions provided to production. So it is clear ODB++M provides the inherent ability to “imitate” production over any time period we are interested in. Additionally, because ODB++M is standard, it is fully consistent across our entire shop floor, regardless of what equipment or processes are running. ODB++M sounds a great start, but how can we practically use ODB++M simulation to get some real value or operational improvements across an organization?
The “playlist” – testing production scenarios
Firstly, ODB++M simulation can provide huge benefits to testing within many organizations or teams. We all want to deliver high quality. Whether we are a manufacturer, an equipment supplier, an MES or solution provider, or a service provider, we want our software products, integrations, equipment, and services to work smoothly in real production. As suppliers we want to demonstrate our products are well tested, they are ready for whatever scenario it will encounter. As customers we rightly have high expectations of suppliers.
However, the challenge is testing in factories, with physical equipment running live production, or even a test or “dry run” production, can get very expensive. It is very time consuming, it has to be scheduled, planned, and in some cases the physical line configurations we are interested in are not yet installed, and do not yet exist in the real world. Important error handling scenarios are often by definition generating scrap, and hence more cost. We must test these scenarios but at the same time we don’t want to run more often than we need to in real production. There are of course ways to manage physically testing but the bottom line is – the challenges remain.
If we don’t test against the physical world, then we need to simulate it, we need to “imitate” it as accurately as possible. ODB++M provides that data, event by event, second by second. It is modelling over time how a physical line of equipment runs, where the product moves next, what recipe is running, what components were used, what tests were done, and what state equipment was in. As an analogy, we all play our favourite songs from our saved playlists or libraries. Perhaps some of you remember CDs, cassettes or even vinyl? In the same way engineering teams, quality assurance teams, test departments, can build libraries of their favourite production scenarios! This is a simple concept, but very powerful.
In fact, not only can you capture or “record” real production from the past by simply recording ODB++M in a log file or database, you can also create virtual production that never existed in the real world, but that you want to test, such as the error handling scenarios mentioned earlier. Perhaps you want to test performance and run a line at triple the speed to be confident your software can handle it, or perhaps test whether the API you work with can handle it. That is likely close to impossible in the real word, but in the world of ODB++M it is trivial to run and now you have confidence that your system has the extra performance if and when needed, and it can be documented. If you want to run your virtual production simulation 24-7 you can easily do that. There is no factory visit, no downtime, no risks, you only imagine the scenario, create it, then “play the song” when you want, where you want.
Changing the focus of physical testing
At this very moment, many Siemens products that integrate with ODB++M are constantly making thousands of simulated tests against an ODB++M library or playlist, many of them past “recordings”, other are virtual scenarios, and fully automated on a bank of servers. If an issue is detected in the real world, the scenario is immediately captured into the simulation library. This then helps an engineer run the simulation immediately to fix the issue, and the simulation remains as an automated test to prevent it ever occurring again in the product. Of course it take effort some investment to establish this kind of simulation platform, but the return on investment is very clear.
This sounds great, but can we it take this further and abolish physical testing? The answer in my opinion, for now, is “No”. There is, and always will be the need for physical testing in real production, the real world is imitated, not replaced – “The Matrix” is not here yet! However with increased focus and progress in simulated testing, we also change the focus of physical testing, because we lower the risk, and the issues being found in physical testing are the issues that only could have been found in physical world. It becomes more focused on “validation”, “quality assurance”, “sign off” which are also much more manageable expectations, as any production manager or supervisor will know. A validation of a scenario, with a very low risk of some issues is a different decision and planning, to a scenario which involves having many unplanned line interruptions and a lot of specialists involved.
Testing is of course a major benefit of simulation, but it does not end there. Simulation provides a way to explore scenarios quickly, again – at low cost. This is in fact what we do whenever new changes are proposed for ODB++M. We introduce the change and then run simulations to evaluate how the change works, how does it actually “feel”, does it work with other existing scenarios? It allows feedback to be captured from a wider audience very easily. It provides more proof of concept without needing to have physical production access. Some of the recent ODB++M changes were tested by members of the ODB++M community on real equipment because they had access locally, but they then easily shared a simulation file with Siemens. We then simulated exactly the same scenario and were able to understand it and implement the proposal.
Shop-floor in your pocket
Finally for the more business focused people amongst us, simulation is a powerful tool to demonstrate product values, features and capabilities, particularly to technical audiences who want to know the detail, get “under the hood” more, get a bit “hands on”, and perhaps less interested in the 50th power point slide. Technical marketing teams really benefit from the simulation capabilities of ODB++M because as one of my colleagues said to me, it is like you have an entire simulated shop floor in your pocket if you need it. If someone wants to really dive into an area of your product and see it some details, look at example data, a marketing engineer, or technical sales person can look into the “playlist” for the scenario there and then, and show prospective customer more detail. It is quite powerful to be able to do that. Again – it does not replace the need to make physical visits to factories and demo real lines and so forth, but as an additional tool it helps.
That is enough for now on simulation and hopefully I was able to share with you some thoughts. I am sure there are many more ideas and thoughts out there, things people are trying and new approaches to solve challenges. Reach out to me anytime, with your own experiences and ideas in this area.
