How to successfully digitalize your shop floor and overcome obstacles that don't actually get in the way.
Machine connectivity can cause problems. And – as is often the case with problems – you only realize you have them when you are in the thick of a project. This can result in delays and significantly higher costs. But all this can be avoided. In practice, it is clear that the majority of all connectivity-related difficulties can be traced back to two causes: The connectivity of the machines is either overestimated – or underestimated. You can avoid both scenarios with this tried-and-tested roadmap.
The crux of machine connectivity is pretty obvious: Digitalization processes in manufacturing usually begin as individual projects. The introduction of an MES, TDM, or CAQ system often covers only partial aspects of manufacturing and eventually leads to numerous silo solutions for data acquisition. The real challenge arises when it comes to the next step. That is when the journey towards Smart Factory, Industry 4.0, IoT, and IIoT is set to continue. It is assumed that previous digitalization gaps have been closed.
Manufacturing companies that implement shop floor digitalization are predicted to experience a productivity growth effect of double-digit percentages*. The magic formula: The seamless use of performance data. To achieve this, you "simply" need to connect all machines and equipment so that they can be jointly planned, controlled, and monitored – all in real time.
State-of-the-art equipment plus sophisticated software solutions create the conditions for this data-driven production. They enable you to:
- Increase efficiency, transparency, complexity, flexibility, and quality
- Reduce resource costs
- Increase customer satisfaction, sales, and profits
But hang on! What does reality tell us?
Factory floors are not designed on the drawing board. Not in everyday business life at any rate. Manufacturing companies are structures that have evolved over time. Structures that could neither predict nor anticipate the technical developments of recent years and are therefore not (fully) prepared for them.
For automated data acquisition, machines must be equipped with appropriate components or sensors. These enable the machines to be connected to a network, thereby creating the data flow that is the raw material of digitalization.
In other words, target-oriented software solutions depend on being supplied with standardized, structured data from all machines on the shop floor. This is a prerequisite that organically evolved shop floors cannot so easily meet.
This is where the aforementioned over/underestimation comes in. The data flow must first (a) be made to flow, (b) standardized, and (c) structured. THESE are the tasks that are underestimated (We can manage that) or overestimated (That won't work. That requires a newer generation of machines).
Why is it that false estimations so often occur at this point? This is how we like to explain it: It is because very few people are aware that people like us exist. We connect machines for a living and specialize in the very challenges that others perceive as daunting obstacles:
- To elicit the required data out of the machines, which they do not provide on their own
- To translate the machine dialects into understandable languages that did not previously conform to any standards
- To accurately filter the data needed for processing from the millions of pieces of data on a shop floor
Why do these tasks require experts? Because these tasks are handled meaningfully and efficiently on the machine level, not on the software level.
Heterogeneity on the shop floor
Shop floors that have "evolved" over time consist of machines from different generations and different manufacturers and/or developers. There are two important aspects to this:
(1) Interfaces – we can distinguish between three types of machines here:
- Machines WITHOUT network components: This concerns older (but often highly reliable) machines and custom developments. In cases such as these, there is often no network connection.
- Bus systems: Communication between two hardware components is called BUS. Different bus systems are used in manufacturing machinery, such as Modbus, EtherCAT, EtherNet/IP, Profinet, Profibus, and CAN.
- IP-based networking: IP-based networking (= Internet protocol) has now become the industry standard. It can be a BUS system (e.g., EtherCat, Ethernet/IP, Profinet, etc.), but not necessarily. The medium via which IP communication runs can be an Ethernet cable, Wi-Fi, 5G, etc.
(2) Protocols and standards – these are the "languages" spoken by individual machines, or to put it another way, the codes and rules to which the machine responds. A distinction can be made here between two basic types:
- Vendor-specific protocols: also called proprietary protocols. This is where the manufacturer of the machine/equipment has defined its own set of codes and rules. This can have various advantages (for example, the speed of communication is usually highly optimized as a result).
- Standardized protocols: These have been defined by associations and consortia to avoid the disadvantages of proprietary protocols. For no matter how suitable a 'tailor-made' protocol may be for a limited area of use, countless protocol variants inevitably lead to problems.
From the variants described above, there may be various mixed versions, a motley crew. For although the aim is to have standardized interfaces and protocols throughout Europe and the world (e.g., OPC UA, umati), industry experts predict that it will take quite some time to achieve guaranteed interoperability between different device manufacturers.
As a machine supplier "by profession", we show you what we can do in this heterogeneous environment. We ensure that data is …
- complete (= from all machines)
- standardized (= in a desired protocol standard), and
- filtered (= meaningfully structured) for further processing.
There are very few machines with which we do not succeed in doing this. With the necessary (machine) know-how and a wealth of experience, practically any machine can be connected. Our knowledge of the machine enables us to obtain data that the machine does not provide. We retrieve it directly from the machine before subsequently translating and structuring it.
For you, this means: There is no reason not to connect machines that are working perfectly well. It does not matter that they do not have the required interfaces, or use any of the standardized protocols, or provide only unstructured data. There is a solution to each of these three tasks! We can do it. And now comes the BUT…
The roadmap for your successful shop floor digitalization
For your shop floor digitalization to be a success, one thing is imperative: you must recognize machine connectivity as a task in its own right and include it in your planning as such. Why is this so important? Because this is where the most common misunderstanding arises – and it goes like this:
- You assume that your future software supplier will integrate the machines – which is not something he can do, because machine-side preparation is not within his scope of expertise or responsibility. Software solutions rely on standardized, organized data.
- Your software supplier assumes that you will provide the required data in a standardized form – which is not something you can do, because your machines are not at all or not fully designed for this.
This is exactly the stalemate scenario you want to avoid. It is where the big pitfalls lie in terms of time and costs. If you only discover the challenge of machine connectivity when you are in the middle of a project, you have neither planned this into the project duration nor accounted for it in your project budget. The "Keep trying until you get it right method", which is so often adopted, is time-consuming and hence cost-intensive and requires strong nerves.
The solution is simple. Plan your digitalization with the knowledge that you need both: the right software solution and the machine connectivity that reliably integrates your machines into the system.
Design your roadmap in a realistic manner along the following lines:
(1) Define your digitalization as a project from the outset
This means: Determine who is responsible, make time available, and define project phases. Base your planning on a time frame of about one year – in our experience, that is a good ballpark figure.
Appoint someone with the following main qualities – interested, organized, and communicative – as the project manager. Speaking from experience, it has proven best to appoint a generalist rather than a specialist as internal project manager. Why? Your project manager should have an understanding of all aspects of the project. In day-to-day project work, this means asking interested questions of all participants/stakeholders, evaluating/weighing up the needs impartially, and communicating information in a way that everybody understands. In most cases, generalists find all these things much easier than experts.
Depending on the size of your project, it may make sense to create an internal project group responsible for the project. Also consider whether you wish to have an experienced external consultant to support you. A consultant can lend his or her expertise to assist management with assessments and decisions and can act as a trusted point of contact for your internal project manager.
(2) Find out EXACTLY what you want to achieve with the planned digitalization.
In other words: Don't go shopping hungry. It never pays off. From a technical perspective, there are many possibilities. But not everything that is possible is useful – or useful for YOU. No software provider can judge what that is for you.
If you give careful consideration to the right things in this phase, you will set your project on course for success.
- What do we want to improve in our manufacturing processes?
- What process are affected?
- What information (evaluations, analyses, planning options) will really help us?
Once again, it has been our experience that the greatest benefits often come from the small improvements. "Big things start small" – this approach has stood the test of time. Why? Because it is very time-consuming if you have to throw too many balls in the air and juggle them all at the same time. After all, you still have day-to-day operations to manage, together with all the associated routines and challenges.
Create a hierarchy: This is particularly important – because it will bring the desired results the fastest. To do this, invite all relevant parties and departments to the brainstorming session. Ask what improvements the project should lead to from the point of view of those involved and affected.
Think about the project beyond the immediate departments and people. In this way, you improve information and identification at the same time – which is a major factor in the success of your project!
3) Create requirement specifications BEFORE inviting potential project partners.
This is where we come back to not going shopping hungry. Don't start without a "shopping list". Half-hearted shopping is also dangerous. If you don't know what you want/need, you often buy what others want to sell you. This will not take you where you want to go. When making your shopping list – your requirement specifications – think about both of the levels addressed: the software and the machine connectivity.
Include the following points in your requirement specifications to provide the suppliers you select with the necessary overview:
(a) List your objectives, including your priorities. In doing so, differentiate what you want to achieve within the scope of the current project and what future objectives you can already estimate. In addition, state the following: What is a must-have (for your project to pay off), what is a nice-to-have.
(b) Include a machine directory. This should show: (i) how many machines and (ii) which machines – type, versions, generation/year of construction – are to be included.
| Machine / Equipment | Year of Construction | Serial no. Machine | Control System | Software Version |
| Index | 2010 | ABC123456789 | Sinumerik 840d SL | SW 4.7 SP6 |
| HERMLE C20 | 2016 | XY1234567892 | Heidenhain TNC640 | 3405994 08 SP2 |
| DMG Mori | 2003 | 123456789XY1 | Fanuc 31i-B | G022/19.9 |
| MAZAK INTEGREX 800V | 2008 | 205848 | Mazatrol Matrix MT | see type plate photo |
Table 1: Example for Machine Connectivity
Example for CNC milling machines: Hermle, Chiron, DMG Mori, Makino, Mazak, Emco, Grob .
Example for CNC control: Siemens, Heidenhain, Fanuc, Mitsubishi. Fagor, Traub.
Experience shows: Machines/equipment up to 15 to 20 years old have a very good chance of being connected. It is also worth checking the connectivity of machines of older generations.
(4) Plan a pilot phase
Theory is theory – practice is practice. Don't miss the opportunity to test your project on a small scale as soon as you can (and to get to know your potential project partners better in the process). Even a test run with one, two, or three machines can give you a very good impression of which of the offered solutions could be the right one for you.
During the pilot phase, you can run through the tasks and scenarios that are relevant and interesting for you, and thereby SPECIFICALLY test the applications under consideration.
Your requirement specifications help you to plan the pilot phase. They specify precisely what you want to achieve. The pilot phase shows you – and your suppliers – whether your expectations will be met.
Plan sufficient time for the pilot phase (as a general rule of thumb: one day on site/software provider). Bear in mind that there may be production stops on the machines on which the pilot phase is being carried out. You also need time to prepare the pilot phase (agree/plan deadlines, lay cables, release the IT system, etc.).
More importantly still, schedule time for the careful evaluation of the pilot phase. Answer the following questions together with your team in this step:
- What have we learned? Were our expectations fully met?
- Have any new ideas emerged?
- What must be added to the requirement specifications and what can (currently) be left out?
(5) Use your experiences for the call to tender
During the pilot phase, you have tested the various solutions, got to know your potential project partners, and honed your requirement specifications.
Now it's time to proceed to the call to tender. In this phase, you will benefit most of all from the steps carried out so far. For you are now able to draw up an extremely detailed call to tender – and thereby receive tenders that you can actually compare.
You are also well-versed with all dimensions of the project and can assess and judge the tenders from the various suppliers. This is because you have now been working on your project for at least nine months (according to our experience): internal clarification phase of six months, three months of preparation, execution, and evaluation of the pilot phase.
In this part of the project, also continue to consider the further internal communication. Report back on the pilot phase, keep your team up to date, make your employees realize that the changes benefit everybody (and that fears are groundless and/or can be incorporated in the project and therefore lead to good solutions).
You will see that when you get to awarding the contract and implementing the project after all these steps, both the implementation and the changes it will bring to your company and your team will be well prepared. The useful added bonus is that you have laid the foundations for all subsequent steps in the process. For all those who witness the success of the initial digitalization steps (even if these are "only" baby steps) are open to other developments. There is nothing more convincing than a successful project!
Let us know if you need our help – even if your project is already underway. There is always a way to connect your machines. We will find it.
Footnote (1): see Axel Tome, Artur Mille: "Digitales Shopfloor Management", 2018 LOG_X Verlag, Ludwigsburg
