There are no specific technical requirements for this chapter. Readers at every level should clearly understand it. Our focus is setting the groundwork for why Industrial IoT is poised as one of the next major turns of the technology crank and how you can move forward with adoption within your industry.

Many software architects are sometimes wary of the hype around new technology. Great ideas and visions are pivots that lead us into the future and guide us in taking advantage of new technology in both our business and personal lives. However, the road to the current state of technology is paved with great ideas that never made it out of the concept phase, and overly aggressive marketing and sales around new (good and bad) technologies have made everyone just a little more cautious.

Usually, at the early stages of some technologies, marketing and sales teams jump in and take over, looking for any opportunity to push an idea or build a prototype with any potential customer, attempting to work together with customers to build a vision of what the future could be. But then comes the hard work of architecture, design, prototyping, rollout, testing, production, and support. Sometimes, the state of the technology isn’t quite ready, and reality intervenes. If you have been burned enough times, it gets harder to reach back in.

Fortunately for us, Industry 4.0 has made it well past the starting gate and into the reality of many organizations. Even though it has been making progress for most of the last decade, there is still a fair amount of work to be done before it can be considered mainstream technology in many organizations. The evolution and improvements in hardware, such as sensors and processors, software protocols, and integration tools, make retrieving real-time or near real-time data from almost any device or area more accessible and safer. The why of data capture and Industrial IoT is what we will be discussing in this chapter, while the how will be discussed in the rest of this book.

Industry 4.0, or the fourth Industrial Revolution, is commonly thought of as the automation and digitalization of industry and manufacturing systems. IoT and cloud technologies have become critical enablers of this effort and provide the ability to integrate and automate machinery to become more intelligent and adaptive. Ideally, this includes adopting artificial intelligence and machine learning to enable systems to self-monitor and diagnose or predict problems that may occur.

This description does provide a bit of futuristic vision, connotating a kind of rise of the machines approach, but it gives us a good starting point on which to base our discussion.

History books and most university classes on this topic will agree that the world has undergone three previous industrial revolutions. For us, how we got to where we are is maybe not as important as where we are going, so we won’t belabor the history here, but we’ll provide some background to aid in your organizational discussions and help us pinpoint the reason for and the focus of this book.

The first Industrial Revolution

The first Industrial Revolution occurred in the late 1700s when mechanization based on water or steam power began. Traditional thought placed this beginning in the 1780s when the first mechanical loom was designed and built. While (relatively) easy to make, replicate, and ship, this allowed for the first major transition from production using hands to allowing machine-based tools to do the work.

Early industrial progress

There are, of course, precursors to the first Industrial Revolution. Recently, on a trip to the Netherlands, I was able to tour some windmills that advanced industry in the region as early as the 1600s, providing improvements to industries such as milling, weaving, and lumber production. Although windmill technology had been in service moving water in the region for centuries before this, this small evolution in leveraging the technology for other types of work allowed the Netherlands to advance into a new era, most notably in shipbuilding. Unfortunately, the technology could not be as easily exported since wind-driven machines were primarily a defining factor of the region. However, the inventiveness of the Dutch and the innovative use of gears, levers, and screws helped build the groundwork for future industry advances, evolving from, for example, farm animals for drawing water or agriculture.

The fact that much of the work was driven by steam was also important. The steam engine’s efficiency had greatly improved by this time, and it was now lighter and more transportable. Coal, and the ability to mine coal in significant quantities, was essential for powering these steam engines. Adapting these same engines moving in one direction or performing one motion to a different degree of movement allowed for more flexibility and complexity in industrial use. The loom was prominent in this phase because the textile industry was labor-intensive, and it became one of the first industries to adopt and see the benefit of new technology.

The second Industrial Revolution

The second Industrial Revolution often referred to as the technological revolution, started in the late 1800s and was a strong driver for the modern world we live in today. The expansion of almost everything we know and use in today’s world started during this period. Beginning with the growth of railroads and telegraphs, industry expanded further, bringing gas, water, sewer, and electricity and increasing globalization toward the end of the colonial age.

The expansion of electricity and assembly/production lines happened within this period. History credits Henry Ford for inventing the assembly line in 1913, paving the way for advanced mass production. Ford is also credited for advancements with the combustion engine, steel, and new fuels and materials that drove this exciting period of change and once again transformed many industries.

The third Industrial Revolution

The timelines are a little intertwined because advancements were frequently made that lent toward each distinct phase of technological evolution. These revolutions can seem almost continuous if traced from end to end with enough detail and advancements. There have always been significant breakthroughs that highlight the end of the last and the beginning of the next phase of advancement. The third Industrial Revolution started in the late 1900s and is called the Digital Revolution. This registers as a shift from analog technology to digital technology. The invention of the internet and smaller computing technologies allowed us to enter the information age.

The invention of the transistor in 1947 is a critical starting point for this era. However, it was several decades before this technology was adapted enough to be helpful on a large scale, with the ability to design and create integrated circuits consisting of hundreds of transistors. Eventually, this allowed the creation of the single-chip microprocessor in 1971 by Intel, allowing for desktop computers to become readily available.

Moving forward and the fourth Industrial Revolution

Hopefully, this short history lesson about the previous three industrial revolutions has helped you understand where we started and assisted you in visualizing how the technology crank continuously turns. Before you know it, advancement has occurred. In addition, each revolution has added tremendous value, advancing civilization, increasing productivity and safety, and moving the entire world another step forward.

The fourth Industrial Revolution should have no less lofty goals, with even more of a potential impact on civilization as a whole. I admit this sounds a bit too rosy, but think about it in terms of the effects on humanity and the world we live in. Efficiency itself means less waste, less use of energy, and potentially less pollution and impact on the environment. That, in itself, should make an effort to move forward worthwhile, and that these improvements can help increase productivity, quality, and revenue is icing on the cake.

Keep this in mind as you delve through this book and determine how to apply some of the ideas to your industry. The immediate goal may be to save or make more money; however, inside, you should know that you are hopefully doing your small part to help save the world.

Achieving the vision of Industry 4.0 requires effort and time and cannot be completed all in one go. This is especially true for legacy or brownfield industrial operations that have sometimes been in service for decades. Additionally, some industries produce widely varied results based on external conditions, such as farming.

Earlier in this chapter, we looked at the standard definition of Industry 4.0. It is a visionary statement, and there are many companies along the path to achieving that vision. However, many companies are just getting started or thinking about how to get started. Industry 4.0 is about data and the management of that data. Alongside data comes the necessary analysis, information, knowledge, and the innate ability to improve by looking at the right things. Industry 4.0 allows us to go beyond the decades-long approach of the status quo. We know from history that at every phase of change, in probably every sector, many felt that change was not required or too fast.

The authors of this book have spent a lot of time working in IoT, going back well over 10-12 years from when IoT was little more than a buzzword. When we think about IoT, our minds go to cheap, easy-to-use hardware and connected appliances or watches. This new crop of inexpensive hardware has opened people’s eyes to what could be done for minimal cost, but for industry, a different level of hardware is often required.

We can use IoT hardware and software to accomplish the goals of Industry 4.0 by providing a robust and industrial-strength set of technologies that allow for the instrumentation and measurement of equipment and its environment. Bear in mind that industry is often conducted in extreme environmental conditions and the cheapest approach is often not the right approach. A trade-off between cost and reliability should be considered since if you have to replace a component too often, then the value can be lost in effort, time, or the loss of data while waiting for the switch to occur.

Let’s talk about the key areas to be considered when turning to IoT as part of the solution. Let’s say we are going to place a simple sensor on or near a device to measure temperature. We don’t need to be specific at the moment, but just consider the conditions that you might be facing, such as the following:

• Tough: Can your sensors and equipment withstand environmental conditions and pressures? Industrial equipment in the field can be in a rough environment. Does the sensor and corresponding transmitter require an ingress protection (IP) or National Electronic Manufacturers Association (NEMA) enclosure rating for protection? IP ratings provide a rating for your enclosure for protection against access to the internal components and protection from the ingress of liquids and dust or dirt, which is essential for harsh outdoor environments. An IP67 rating indicates a solid enclosure that is protected from the ingress of dust and protects against temporary immersion in water up to a few centimeters. NEMA ratings are the same as IP ratings but provide additional classifications against corrosion and hazardous locations. For some environments, such as oil and gas, a NEMA Class I or Class II enclosure is required due to the presence of corrosive liquids, flammable gasses or vapors, or combustible dust. These environmental conditions and requirements can add additional costs and time to your effort in sourcing, testing, and possibly certifying your components for use in the field.
• Easy to deploy (and maintain): Make it as simple as possible to ensure speed and accuracy when deploying equipment. This ensures that deploying and registering your sensors and equipment is simple, almost bulletproof, for the engineer on site. When deploying a sensor to a piece of equipment or a location, we have to ensure that once the sensor is in place and operating, we can tie it back to the right location. Without that, the effort is useless, and none of the data further up the chain will be reliable. There are several options here. Mobile apps with barcodes and even manual configuration are fine as long as the setup can be done correctly and consistently. Additionally, the sensor should be easy to attach and place. OK, simple is not always possible, but as much pre-configuration as possible should be considered, leaving the engineer to do as little as possible on-site to complete the setup and installation. Runbooks should be well-defined and include any troubleshooting information that might be needed in the field. This is especially true if the deployment people are not experienced in the new technology.
• Scalable: The ability to quickly deploy many sensors in the field should be considered. This can mean dozens, hundreds, or thousands of sensors across multiple locations or across the globe. Both hardware and software can be a concern when thinking about scalability. Something easy to deploy and configure can be deployed by the thousands; however, if the software or storage is not configured to manage the data, it may result in wasted effort. Cloud technology will help with the software part, although the application requirements to view and analyze data need to be able to keep up as the system grows. This means data systems and analysis should be designed to accommodate the potential millions of readings you might expect from all those sensors.
• Reliable: This ensures sensors and monitoring will keep working over a long period of time. This is not the same as a sensor or node being tough. It’s about reliability. Reliability is much more important because now we are talking about the electronics, rather than the casing and packaging of the node. Do the electronics have sealed or glued connections? Are the sensors potted or otherwise protected? Potting means filling or surrounding the electronics with some type of gel or epoxy resin, essentially encapsulating the electronics to minimize the dust, vibration, or liquids that affect them. Of course, before going to this extreme, quality control and using high-quality components are recommended. Hot glue on your connections can be the first line of defense against the loosening of wires. If you go to the extreme of potting your components, be aware that it cannot be undone, so when a part goes bad, a replacement for the entire assembly will be needed, which may be costly. Carry out a cost-benefit analysis of the best approach based on your industry to make the right design decisions.
• Secure: Make sure data and systems are protected from malicious actors or data theft by unauthorized parties. We will talk about security throughout this book. Using IoT technology can potentially leave security holes across the entire data stream. There are several aspects here to consider. Ensure that data is secure while traveling upstream, and protect endpoints so that fake data cannot be introduced into the system to influence results or actions. Since we are talking about the endpoints in sensors or nodes, physical security is the first step to consider here. Do you need to apply any physical security to the deployment location? And if not, what type of tamper monitoring can be put in place to alert you if something seems amiss? Once data hits the cloud, traditional IT security methods can come into play, but with equipment in the field, your system can encounter many different types of threats.

If you are in the industry already, you will already know some of this; if you are an operator, you will know your environment intimately. But it is still worth considering the environment and defining some basic requirements alongside your goals. This is an excellent point to think about the domain you are considering and create a simple checklist with critical criteria that you can build on as we go forward. These considerations go hand in hand with each other and drive toward a common goal. Using the preceding criteria, along with more to be added as we go, can help you navigate decisions and communicate to others the expectations of the technology.

Sensor technology

We use the term sensor technology broadly to include both the sensor or sensors involved in instrumenting an environment, but also the sensor node that reads the data from the sensor and transmits it to the receiver. We separate these currently because they do not always go hand in hand. Sensor technology is constantly evolving and transmission protocols, such as low-power wide-area network (LPWAN) and 5G, continue to evolve. The sensors you wish to use may have specific characteristics and may not always be compatible with a sensor node for transmitting data on the protocol that you have defined. Let me share an example.

Several years ago, during the Wild West of IoT evolution (just kidding, it’s still the Wild West), one of the authors was involved with a proposal for a large city in Nevada; you can probably guess which city. Our partner in the deal was an IoT start-up; actually, it was way more than a start-up, with millions in funding, but it was relatively new to the IoT space. The company had some fascinating communication technology, which should have been a strong competitor to cellular technology and most LPWAN technologies. It was low power and could send data over very long distances, outdistancing other technologies such as LoRa (from long range) by miles.

This company spent a lot of money and energy on trying to sell and further develop its network, and since fewer towers or hotspots were required to blanket an area, they felt they could cover large areas, such as a city, with relative ease and lower cost. While this was probably true, little regard was given to the fact that no sensors or sensor nodes were available to use on the network. Chips were available and provided by the network provider, but the cost, time, and effort were left to sensor vendors to implement. Essentially the sensor vendor or consultant had to make a bet on this working based on little more than faith in the network company. In hindsight, it’s a bet we are glad we didn’t take.

Unfortunately, this turned out to be a failed strategy since the investment was too significant and complex compared to more available options at the time, using protocols such as LoRa, Sigfox, and LTE. I’m still disappointed the company didn’t have the vision to see this hole in their strategy, and they have moved into the realm of also-rans in the IoT space.

The key takeaway here is to keep in mind the following:

• Can your sensor node or transmission unit communicate back to the cloud with your chosen protocol, or set of protocols if you need redundancy?
• Can your sensor node communicate with your actual sensor or set of sensors to read the measurements for data transmission?

There can often be a mismatch here as the sensors themselves can use all kinds of unique protocols. For example, SDI-12 is a standard serial communications protocol used in agriculture and weather sensors and can be challenging to read if the sensor node is not designed for it. The protocol was defined in the late 80s and transmitted ASCII characters over a single data connection. There are many examples of serial protocols in place for industrial systems that can be decades old but are still very much the standard.

Another example is if you need calibrated sensors, such as temperature sensors, that must follow NIST standards to ensure the results adhere to standards. If calibrated temperature sensors using your defined communication protocols are not commercially available, then you have limited options.

Every day it seems, the sensor world gets a little bit brighter as a vast array of sensors, edge devices, and transmitter units or nodes become more readily available. Many of the most popular protocols are available, with new ones coming on slowly as new network technology is better adopted by the community and becomes more readily available. However, there are still sensor solution gaps for many situations.

One of our favorite options for this problem is from a company called Libelium out of Zaragoza, Spain. Libelium offers a robust mix-and-match approach to sensors and communication options of all different types. For example, you can choose sensors for measuring air quality, water quality, security, and agriculture or for integration into industrial protocols such as Modbus. You can pick a communication protocol to connect the sensors and send measurement data to an existing application or web service. Protocols include using anything from LoRa to Wi-Fi to 4G. This flexible approach makes it easy when you try to adhere to a standard communication protocol but cannot find an appropriate sensor that works with your chosen standard.

Cost can certainly be a factor, especially at scale, and while prices seem to be continuously going down, here is where the myth of IoT, again, seems to get in the way of Industry 4.0. You get what you pay for, and this can be crucial in harsh environmental conditions and areas where you need to provide a standard approach.

IT versus OT

There is still a lot of confusion around information technology (IT), operational technology (OT), and this idea of convergence. But essentially, it is a simple concept to understand.

IT is something we are all familiar with in our daily lives. We run applications on our phones or laptops. Many of these applications run on servers or in the cloud and process data-producing orders, sales, and directives or provide some type of analysis. This is the IT world that we know today. It’s a reasonably open world, and access can be gained from anywhere (provided security concerns are followed).

OT, especially legacy systems, can be considered a more closed environment. OT ends within the walls of the factory. When you think of OT, think of supervisory control and data acquisition (SCADA), which is also run by servers but interacts with devices within a defined area of control. At a large scale, consider a power plant or water treatment plant. The pump shuts off when the water in a tank gets too high. Too low, and it starts back up again. Monitors and alerts allow operators to visualize and help manage what is taking place with appropriate alarms and controls.

Industry 4.0 and organizational alignment

Figure 1.1 illustrates how different areas within the business fit together and into the big picture. In order to work, there is a strong dependency across IT, operations, and business and management; all stakeholders must work together to realize the benefit.

Figure 1.1 – Industry 4.0 organizational alignment

OK, what is the big deal? The big deal is that IT’s primary goal is to provide the business and management with information and the ability to support the decisions and operations of the company. How many widgets were produced? Or how many barrels were processed? How many were sold, and at what price? The business lives and dies on this information and data being available faster and more accurately to provide a competitive edge. Often what is missing is an insight into the real-time production of widgets or processing of barrels. Newly built or upgraded factories can provide real-time information, but in legacy systems, even relatively young ones, that information is hidden. And in production, modifying (reverse engineering) devices and machines voids warranty and, if not done correctly, may lead to complications. With the emergence of IoT, we can bring some of that data from the closed OT world into the often more integrated IT world, where it can be used more effectively.

The focus of this book is on getting the hidden data, storing and processing it, and then using this information effectively.

The business is not the only one to benefit from introducing new data. Operational teams will gain insight into the equipment and production that they didn’t have before. Uptime and maintenance can be improved, cost reduced, and throughput increased as a new understanding, and a new normal of the environment begins to emerge. The full benefit of digitalization should become clear in the rest of this chapter and throughout this book as we share examples of collecting data and then using that data to realize value across the organizational spectrum.

You can get there from here

Industry 4.0 is driven by IoT, but it is just one part of the picture. A big part, granted, as it allows visibility into equipment and operations as never before. A longer roadmap is required to achieve the vision of digitizing your industry and the transformative changes that can take place.

Important note

We are not a fan of big, complicated, eye-chart-type visuals, so throughout this book, we will keep the visuals simple and coherent to allow you, the reader, to immediately understand the concept rather than asking you to try and understand something overly complex.

Figure 1.2 illustrates a basic roadmap toward digitizing your industry or moving toward Industry 4.0. We have broken this down into four primary areas of consideration for improvement. Within each of these areas, there is a vast number of considerations both on the technical and business side to consider.

For many, the status quo or current state of their process is operate. Consider this business as usual, and maybe decades-old processes that, for the most part, just work. There may be some instrumentation, perhaps even a lot, but no cohesion or integration across machines, systems, or plants. Everyone knows we can do better, but how do we move forward? Figure 1.2 illustrates a set of steps for continuous improvement in your equipment and environment. Instrumentation and acting on it improves both the business and technical responses of the organization.

Figure 1.2 – Industry 4.0 roadmap

Let’s talk about each step of the process outlined in turn. We have labeled each area based on the technical changes because that is the focus of this book. However, this can be adapted based on your principal needs.

Instrument and connect

Moving beyond the general operate state requires in-depth visibility of your systems and environment. Consider this the instrument phase, where the goal is to start to gather data from your systems and environment. The other side of the equation is to know what should be instrumented and why. This effort of instrumentation and collecting measurements is where business and operations can collaborate to ensure that the data collected is needed and understand how that data will be used to drive processes and the business forward.

It is usually not the best strategy to jump in and instrument everything. While it may seem like more is better and that you have nothing to lose by doing so, spending time and money on equipment, manpower, bandwidth, and storage for data that is never used ends up being a losing proposition. Once committed, it may require ongoing maintenance for data that does not provide good value.

Another question to ask is how much data is needed. This depends on the velocity of what you are measuring and collecting. Some systems can churn out hundreds of measurements per second. How and where should this information be stored and analyzed? Does all of it need to go to the cloud? Can we process this on the edge and provide aggregate results? What are the pros and cons of taking an approach toward managing this data? Business and operations should be involved intimately in these discussions to help drive what level of granularity is needed and how it will be used. This in turn can drive IT decisions for data management and processing.

Baseline and analyze

Baselining your system’s normal operating environment can be an eye-opening experience. Sometimes (actually a lot of the time) we don’t really know what normal is for our equipment until we measure it and then see it in some graphical format. SCADA systems often have this insight into pressure, temperature, and flow characteristics, but not all industrial operations are driven by SCADA, or the information is hidden from all but on-site equipment operators. The insight gained here can be enormous. Measuring a handful of values can provide deeper information about the working condition of a piece of equipment or an end-to-end system and, as we will see later, drive efficiency and potential maintenance issues. Understanding the baseline of system performance and conditions at a known production rate can be powerful, as well as asking questions such as, what happens when the production rate goes up, and how does that affect the machine conditions?

Defining a baseline can take a long time; it is not done in a day or even a week. Expect at least several production cycles, which could be seasonal-based activities that could take months or years. Hopefully, most cycles do not take that long, but if your industry is influenced by weather or environmental conditions, there is that possibility. You can continuously gain good insight by getting comfortable with what your baseline looks like along the way, but unexpected curves and influences only occur with time.

Prediction and alerting

From a technical side, we have many opportunities. Now that systems are being more closely monitored, you should expect to see variations in the data as problems occur, and equipment shuts down. Maybe there were some unexpected vibrations or a temperature rise before it occurred. Can we monitor for a particular set of variances? Do the vibrations occur when a part is ready for replacement or maintenance? This is the beginning of condition-based maintenance, where new data or real-time monitoring of the environment can alert the operator to a possible set of conditions that may fail.

To accomplish this, we need to start to build predictive models. Tooling today can make it a relatively straightforward process to create a predictive model; however, much of the work in the baseline phase will help you determine which data to prepare for modeling. Generally, we are looking at data to help predict downtime or failures of equipment or systems; however, does the data do this? We will dive into some details about predictive modeling and how to use this in your architecture in the coming chapters.

We can often start our journey by using simple thresholds or comparisons on specific values or sets. This is especially true when you know what specific events or conditions you are looking for but are not quite sure how predictive models will advance your cause. Does the temperature rise above a specific degree? Does the energy usage on a pump get higher while the pressure gets lower? These are simple examples, granted, but powerful tools in helping to determine when something might need to be checked. At this point, we are still triggering more manual alerts, effectively telling someone to check something. This could be as simple as an email or SMS, or a more advanced trouble ticket being opened automatically on your enterprise asset management system.

But really, we can now take this further into the business side of things and better understand production cycles and issues and capacity constraints, not only of finished products but subprocesses that may cause bottlenecks.

Automation and improvement

Industry 2.0 and 3.0 brought a lot of automation into manufacturing and processing. Our focus is more on the automation of the overall business and what is produced. The ability to monitor and eventually steer your production closer to real-time allows the business to be more agile and respond more easily to customer demands. This is a topic well beyond the scope of this book, and would possibly include connecting customer demand, supply, and fulfillment, as well as the digitalized production or factory that is our focus here.

However, with a deeper analysis of your historical data over time, a more detailed analysis can occur of where and when improvements can be made.

Visibility is everything

We probably can’t say this enough. Possibly, this is the gist of the entire book, along with some focus on what to do after you have better visibility. It was mentioned before that understanding your baseline, or the normal operating conditions of your environment can provide clear insight into what is truly normal and when some type of abnormality occurs. This can only happen with clear instrumentation. This is true in almost any industry or science. Most experts will explain that the instrumentation of your environment allows you to gain new insight with a precision not previously available. Software developers who have used deeper inspection, such as bytecode instrumentation or injection, can easily explain the advantage of increased visibility into aspects of a running system. The same is true for physical systems and being able to view and analyze the physical characteristics of a piece of equipment or an environment.

Another aspect to consider is global or widely distributed operations. Modern equipment or systems can be outfitted with all the instrumentation needed for the safe and efficient running of the process. However, what about systems that are geographically distributed across vast areas? Combining and even comparing information from systems globally can provide new opportunities for decision-making.

Along this path should be a feedback loop, allowing adjustments and updates across the entire monitoring chain.

Business driving innovation

A quick web search will provide an abundance of IoT information, specific lists of ideas, examples, or use cases for implementing IoT for your industry, and the value it provides. Sometimes there are interesting use cases, but often it is driven by marketing and sales looking to sell their solution. Unless you have a good working knowledge of an industry, this can be misleading. Earlier, we mentioned that just because you can instrument something does not always mean you should. Time and cost considerations should come into account. Consider the cost of adding sensors to gather information, but also the data collection and maintenance costs of continuing to gather data.

IT, operations, and business stakeholders need to work together to understand what it is that they want to achieve. Then real subject matter experts need to be involved in telling you how to get it and then interpret the right data points to achieve those goals. Operations understand better than anyone how to develop, manufacture, or produce materials or goods. Business stakeholders know how to price, sell, and distribute those goods to end customers. There are nuances in business and operations that the other may not understand intimately or agree with, but working together to achieve better visibility and control can be a powerful weapon for competing on the global market.

The truth is, business and management may not know what they need to instrument at a detailed level. But they do know what information they need to make decisions, such as better overall equipment effectiveness (OEE), downtime reports, or more detailed forecasting for service lines over a period of time. OEE is a process for measuring manufacturing productivity by looking at equipment availability and performance, and the quality of manufacturing output. Operations can then make an informed decision about what they need to do to obtain and provide that information. It’s a complex process that is greatly oversimplified here, but hopefully provides some guidance that no one area of the business should work in a vacuum on this endeavor.

So far, we have provided a big-picture overview of Industry 4.0, the digitalization of the industry, and Industrial IoT. There are multiple approaches to accomplishing systematic improvement in your production and management of equipment and processes, and the roadmap is one approach. Moving forward, we want to dig deeper into some of the technical aspects of starting your journey and adopting a digitalization mindset and approach. What are the steps and goals for moving forward and getting incremental value along the way? In addition, what are the pitfalls in adoption and understanding how difficult it will be? We will be exploring more of the idea of instrumentation, analysis, and convergence for providing value across all stakeholders.

Rarely does an opportunity come around in the industry for all aspects of the organization to come together for everyone’s benefit. Industry 4.0 allows that to happen. The digitalization of industry can benefit all aspects, allowing the business to make better decisions around schedule, price, and volume and providing operations with better tools to make decisions about maintenance, downtime, and upgrades of equipment within a plant or factory.

Evolving toward IoT and Industry 4.0 allows for many things to occur. Maintenance cycles can be improved, which positively affects planning and production. The roadmap toward the continuous improvement in your maintenance approach outlined in Figure 1.3 provides an idea of how your outlook and planning can be improved over time.

Figure 1.3 – Driving toward common operational goals

This is not an overnight process to achieve results with instrumentation and monitoring improvements, so we wanted to talk about the progression and the maturity curve that might be adopted moving forward.

Reactive and preventative maintenance

Many companies are in the first two categories of reactive or preventative maintenance.

Reactive maintenance is where we basically run our equipment until it breaks. When a piece of equipment or production line breaks, or when we notice some issues with the machine, then we fix it. For example, we replace the belt when it breaks. This is fine in some cases where the fix is simple and relatively inexpensive, but if we need to order parts or the replacement effort is extensive, it could result in unexpected downtime and poor production results if the break is in the middle of an important production cycle.

Preventative maintenance is a little better. It’s often driven by the calendar or perhaps usage-based (number of hours), similar to changing the oil in your car every few thousand miles. It may be driven by an enterprise asset management tool that is put in place to manage inventory and track and manage assets based on tickets from the field or by using the provided manufacturer guidelines for scheduling maintenance. So, for our previous example, the belt is scheduled to be replaced every few thousand hours based on the manufacturer’s recommendation.

The advantage of preventative maintenance is that downtime can be better scheduled, and unexpected downtime can be reduced. It may be the best you can achieve with in-depth instrumentation; however, it may not be enough. One concern is that you may over-maintain your assets or under-maintain them, which can cost you more in maintenance or asset replacement costs.

Even as we move further down the optimization chain, I don’t think we will ever really replace these types of maintenance. Things happen, and reactive maintenance is necessary. And yes, that belt should be replaced on the recommended schedule. Production machinery almost always needs constant love and care. But the long-term benefit is that you don’t have to devote attention to it as if you were in the Army, where if you are not training or sleeping, you are performing preventative maintenance on your vehicles, weapons, whatever, whether it is needed or not. Of course, in this case, the ultimate goal is to keep you alive, so not a bad thing in context.

Condition-based maintenance

As we start to initialize data and collect more information from the individual assets, we can move to condition-based maintenance. We can look closer at the real-time conditions around that asset. Measurements such as current output combined with solar conditions or compared with other solar modules can help us understand whether a component is underperforming and may need to be looked at more closely.

With condition-based maintenance, we get into the habit of not performing maintenance too early or too late but in line with actual data from the equipment and its performance.

Predictive maintenance

Predictive or prescriptive maintenance takes this one step further by adding machine learning modeling to remove the human component from the monitoring process and provide feedback based on what it has learned about optimum operating conditions. Some would argue that these are two different things.

Predictive maintenance helps to forecast potential problems or outcomes with your environment. Prescriptive maintenance helps to provide recommendations based on those outcomes. Neither of these is new to us. Consider the wayfinding application on your phone, which tells you in advance of a delay ahead on your route. Many of these applications will prescribe alternate routes and determine the time savings or delay.

Eventually, some companies may lean into risk-based maintenance, which helps you consider the risk that this part will fail. How will production be affected? Or what downtime may occur if it does fail? Essentially, what is my cost if I keep running and a failure does occur?

Approach with caution

We have all seen or heard of the don’t-touch-it mentality from production teams who just need to keep their system running. When systems are old, decades old, there can be a lot of lost knowledge about how those systems work. Parts may be hard to replace, and sometimes, things work that shouldn’t. These are some of the challenges that operations teams face, and it can be hard for anyone outside those teams who need to get a better look at what is happening inside.

These types of environments and equipment need to be approached with an abundance of caution. Trust is a big factor, and sometimes IT needs to earn trust and not come in like a knight on a white horse, suggesting it will fix all the problems of the day. Everyone in the organization needs and wants progress, from the boardroom all the way to the equipment operator on the shop floor. However, moving too fast in some challenging environments is the easiest way to lose trust within the organization.

We have found from experience in many different industries that most operators love to share information about how they do their job, how they treat their equipment, and, mostly, how things could be made better. Having worked in consulting for many years, it is incredible what you can learn when you talk to subject matter experts in the field, learning everything from farming to fracking, with experts always being generous with their time when approached respectfully. Here are a few simple steps as an approach to this. Some of these tactics seem almost silly to say out loud, but they’re essential to keep in mind:

• Listen and learn: Understand what all the stakeholders know about a system and how it works. What are their concerns, big and small, and what suggestions can they provide for improvement moving forward?
• Define success: Understand what success means, whether this is for one piece of equipment, an entire line, or the plant. Knowing your end goal can help you stay focused and on track.
• Research and share: Learn more about the options you may have for instrumentation and sensor deployment. Share what you have learned with the operators and discuss the pros and cons. Do not get fixated on a single path until you find some general consensus on what could work. Even if you know you are right, it won’t hurt to bring everyone along with you through consensus building.
• Proceed with caution: Finger-pointing when something goes wrong can be a disaster, not only for the people involved but for the project as a whole.

Sending up trial balloons (or conducting a spike in the agile world) for testing can be a viable approach. Testing out different sensors or interfaces without full commitment will allow you to evaluate the pros and cons of the approach and share the results with stakeholders.

Of course, all these guidelines are focused on production equipment, when a mistake is liable to cause serious problems through equipment downtime or worse. A standalone temperature sensor doesn’t require nearly as much effort, but it’s probably not wise to grab the first one you see and run with it. Even low-impact sensors should be evaluated against some of the guidelines discussed earlier. We outlined some considerations when sourcing equipment and sensors, but we have not addressed the approach for determining whether the sensor can provide the correct measurements. Ensure that you discuss equipment tolerances, temperature fluctuations, and pressure and vibration values. This allows you to choose sensors that can operate within the machine tolerances and provide measurements at the right frequency.

Architects are big fans of patterns and standards. Doing something in a similar and proven way is common in just about every type of job or industry, especially those that produce physical or tangible results. The size or strength of the material can determine much about how to build something, and it helps to define the time and cost that goes into the build. We can translate this directly into building something less tangible, such as software. With Industry 4.0, we have the best of both worlds, hardware, and software, allowing us to use traditional engineering techniques and hopefully rigid hardware and software engineering processes.

In software, we often call them best practices, but it is not always everyone’s best practice. Sometimes what works for one company or team may not work for another. Or similarly, differences occur across industries or environments. With this in mind, our goal is not to prescribe exactly how things work but rather to provide a set of strawman models based on generally accepted industry best practices that can be adapted to your situation or solution.

Throughout this book, we will share approaches and patterns that can be adopted but don’t be afraid to go your own way (within reason). In addition, technology changes over time. What might be the best practice today may not be the same tomorrow as new approaches evolve for achieving your goals.

Observability

We have mentioned the idea of observability in this chapter, but let’s review it in more detail. Observability is not quite the same as monitoring, but there are a lot of different opinions on what the difference is. The name is not that important, but conceptually you should understand the difference. Our best definition to build upon monitoring techniques with an observational approach is as follows.

Monitoring involves collecting data from sensors, logs, and production or machine metrics. This allows you to understand the current state of a system, whether that be a machine or even the components within your IoT application. Monitoring enables you to know whether something is working and when a system or piece of equipment is down.

Observation takes it a bit further and allows you to better know why something is down or not working at the optimum level. Observation requires monitoring and possibly additional instrumentation at multiple levels. Consider the following possibilities:

• To see how systems work together: In IT, it is often possible that one system or process affects another, but clearing away the potential issues to get to the root of the problem can be challenging. For example, a web page is loading slowly, but the problem is that the database is overloaded or that the query is more complex and takes additional time to complete.
• To gain a deeper understanding of an internal systems operation: In the previous example about the database, only through deeper instrumentation, such as bytecode injection in the code world, could we gain insight into what is happening. That instrumentation level also allows us to see how components work together and understand how one depends upon another in the process flow.

To summarize, we can distinctly define the difference between monitoring and observation:

• Instrumentation supports monitoring, which tells you that something is wrong
• Monitoring supports observability, which tells you why something is wrong

As I mentioned, there are different interpretations (I have seen examples where this is reversed), but this seems to make the most sense. In reality, the end goal is something we all want to achieve. We want complete visibility into our systems and processes so we can handle problems and improve the outcome.

Repeatability lowers cost

As you move forward toward advanced digitalization, there will be a lot of moving parts. Both hardware and software will need to constantly adapt as the solution evolves. For large implementations where there is a lot of equipment, or the environment is widely distributed, it may take a lot of help to deploy and manage equipment. Items to consider, include the following:

• What type of equipment are you using, and can it be deployed or configured to handle multiple uses or types of equipment?
• What is the best purpose-fit type of sensor monitoring equipment (single-purpose or multi-purpose equipment)?
• How does sensor monitoring equipment stand up in terms of cost, training, installation, and maintenance?
• How much field training will be needed? Simple plug and place, or complex configuration and management training and runbooks?
• How will software need to be adapted as sensors and monitors are deployed?

As your solutions evolve, consider these guidelines and how you can streamline the deployment and management of the solution, ensuring that as much repeatability as possible is followed. If sensors and data collectors need to be configured, do the software and cloud need custom work? Think about things such as custom tags. At scale, how much work will it be to collect and store data from hundreds of pieces of equipment and thousands of tags?

The overall focus of this book is implementing Industrial IoT and leveraging AWS cloud technology to achieve the goal of digitalization of your industry and environment. This chapter was designed to set the stage and provide a basic understanding of Industry 4.0, including its purpose and a view into the road ahead, helping you to have a better understanding of the end vision. A strong roadmap and vision, guided by business goals and coordinated with operations and production teams, can help you stay on track and ensure that everyone buys into the process.

In the coming chapters, we will focus on more technical details of how to achieve some of those goals toward instrumenting, collecting, and using data within your environment. This is the fun part of the process for IT geeks who are interested in learning and using new technology. The advent of IoT has opened the availability of hardware to software engineers who don’t always have the opportunity to work with both. Hardware, software, networking, and analytics are now considered the full stack of most IoT engineers and open up new opportunities for interesting solutions in the industrial space.

In the next chapter, we will outline our overall architecture planning approach. We will describe the main architecture levels and key components to build a successful and scalable Industrial IoT platform. Starting with the basics will provide a starting point for adapting some useful architecture concepts to your environment as you initiate or continue your IoT journey. We will also talk about the roles of the IT architect and different types of architect roles and discuss how you can add the most benefit to the project’s success.

For now, grab a cup of coffee, sit in your favorite chair, and enjoy!