Technology Will Keep Changing, But Fundamentals Will Not: Navigating the Shift from Industry 4.0 to Industry 5.0

Technology in the industrial world is moving faster than most organizations can comfortably absorb. Just as many companies, engineers, and students are still working through the practical realities of Industry 4.0, implementing automation, connecting machines, and building data-driven processes, the conversation has already started shifting toward Industry 5.0. For a lot of professionals, this creates a real sense of confusion. How can we be expected to master one industrial revolution when the next one is already being discussed before the first is even fully adopted?

 

This is a fair concern, and it is one worth addressing directly. But there is a simple truth that cuts through most of this confusion: technology will keep changing, but fundamentals will not. Understanding this distinction is the key to staying grounded, confident, and genuinely capable, no matter how many new buzzwords, frameworks, or industrial revolutions come along.

The Nature of Constant Technological Change

Anyone working in engineering, automation, or manufacturing today has already witnessed this pattern repeat itself many times. Tools change. What was considered advanced automation a decade ago is now considered standard practice, and what is considered cutting-edge today will almost certainly be considered basic within another decade. Machines are becoming smarter, capable of self-diagnosis, predictive maintenance, and increasingly autonomous decision-making. Automation itself continues to improve, moving from simple fixed-sequence control into flexible, adaptive systems that can respond to changing conditions in real time. Artificial intelligence is becoming more powerful and more embedded into everyday industrial processes, from quality inspection to predictive analytics to autonomous scheduling.

None of this is going to slow down. If anything, the pace of change is likely to accelerate further. New industrial revolutions will continue to arrive, each with its own name, its own set of promises, and its own learning curve. Industry 4.0 will not be the last framework of its kind, and Industry 5.0 will not be either. This is simply the nature of technological progress, and professionals who expect this pace to stabilize are setting themselves up for ongoing frustration.

Why Fundamentals Remain Constant

While tools, machines, and technologies are in a constant state of evolution, certain fundamentals remain remarkably stable across every industrial era. These fundamentals are what actually determine whether a professional, a team, or an organization succeeds, regardless of which specific technology happens to be dominant at the time.

Strong engineering principles do not change just because a new automation platform is introduced. The physics, the logic, and the discipline behind good engineering remain the same whether you are working with relay-based control panels or the most advanced AI-driven systems. Problem-solving ability is equally timeless. The specific tools used to diagnose and fix a problem may evolve, but the underlying skill of breaking a complex issue into smaller, manageable parts and systematically working through it remains just as valuable today as it always has been.

Process understanding is another fundamental that technology cannot replace. No matter how advanced a control system becomes, someone still needs to deeply understand how the actual physical or chemical process behaves, what its constraints are, and why it responds the way it does under different conditions. A quality mindset, the discipline of consistently caring about doing things correctly rather than just quickly, continues to separate good engineers and technicians from great ones. Safety awareness remains non-negotiable in any industrial environment, regardless of how automated or intelligent the surrounding systems become. Human creativity continues to be essential, because even the most advanced AI systems still rely on human insight to define problems worth solving and to interpret results in meaningful ways. And continuous learning, the willingness to keep growing and adapting rather than assuming your current knowledge is enough, is arguably more important now than at any point in industrial history.

These fundamentals are not tied to any particular version of an industrial revolution. They are the foundation that has always mattered, and they will continue to matter regardless of what Industry 6.0, 7.0, or beyond eventually looks like.

Understanding the Real Difference Between Industry 4.0 and Industry 5.0

Part of the confusion around these terms comes from not clearly understanding what each one is actually emphasizing. Industry 4.0 was primarily focused on automation, data, and connectivity. It was about connecting machines, collecting vast amounts of data, and using that data to automate decisions and processes more effectively than ever before. This included concepts like the Industrial Internet of Things, cyber-physical systems, and increasingly integrated digital ecosystems across a factory or plant.

Industry 5.0 does not replace these ideas; it builds on top of them while shifting the emphasis toward human collaboration, sustainability, and resilience. Where Industry 4.0 was heavily focused on efficiency and automation for its own sake, Industry 5.0 recognizes that technology should work alongside people rather than simply replacing them, that industrial processes need to be sustainable for the long-term health of the planet and society, and that systems need to be resilient enough to withstand disruptions, whether from supply chain issues, natural events, or other unexpected challenges.

Understanding this distinction removes a lot of the confusion. Industry 5.0 is not an entirely separate revolution that makes Industry 4.0 obsolete. It is a natural evolution that reframes the purpose behind the technology, making sure that connectivity and automation serve broader human and environmental goals rather than existing purely for their own sake.

Building a Strong Foundation First

Given how quickly new terminology and technology trends emerge, the most practical approach for professionals, students, and businesses alike is to stop trying to chase every new label and instead focus on building strong fundamentals first. Once that foundation is genuinely strong, adopting any new technology, whether it is labeled Industry 4.0, Industry 5.0, or something entirely new in the future, becomes significantly easier.

This is because new technologies are rarely built from scratch in a way that disregards everything that came before. They are almost always layered on top of existing engineering principles, process knowledge, and problem-solving frameworks. A person with genuinely strong fundamentals can pick up a new tool relatively quickly, because they already understand the underlying logic of why the tool exists and what problem it is meant to solve. Someone without that foundation, on the other hand, ends up learning tools in isolation, without truly understanding their purpose, which makes every new technology feel like starting over from zero.

Conclusion

The future does not belong exclusively to those who chase every new tool or buzzword as soon as it appears. It belongs to those who understand why and how those tools should be used, professionals who can look past the marketing language of any given industrial revolution and see the underlying engineering and human principles that remain constant beneath it. Technology changes fast, and it will only continue to change faster in the years ahead. But fundamentals create long-term value. Strong engineering principles, real problem-solving ability, deep process understanding, a genuine quality mindset, unwavering safety awareness, human creativity, and a commitment to continuous learning will remain relevant no matter what the next industrial revolution decides to call itself. Build that foundation first, and every new wave of technology becomes an opportunity rather than a source of confusion.

 

Error in Data Display During SCADA and PLC Communication: The Hidden Cost of Wrong Data Types

Anyone who has spent time commissioning a SCADA and PLC system has probably faced a moment of confusion when a number on the screen simply does not look right. Sometimes the value is completely wrong, showing a number that makes no physical sense compared to the actual process. Other times the display does not show a number at all, and instead shows a row of hash symbols, ####, in place of the expected value. Both situations point to the same underlying question: is this really a communication failure, or is something else going on?

In a surprising number of cases, the answer has nothing to do with the communication link itself. The PLC and SCADA may be talking to each other perfectly fine, exchanging data exactly as configured. The real issue is that the data is being exchanged and displayed using the wrong data type. This is one of those small, easy-to-overlook details that can cause hours of confusion during commissioning if it is not caught early.

Why Data Type Selection Matters So Much

Data type selection is a foundational part of both PLC programming and SCADA configuration, and it is easy to underestimate how much weight it carries. On the surface, some data types look almost identical. They are all just numbers, stored somewhere in memory, right? In reality, each data type defines a specific number of bits, a specific range of possible values, and a specific way of interpreting whether the number can be negative or only positive. A mismatch in any of these details, even a small one, can cause a perfectly valid raw value in the PLC to be displayed completely differently on the SCADA screen.

This is exactly why understanding the common integer data types used in modern PLC platforms is so important:

• USInt – Unsigned 8-bit integer, storing values from 0 to 255.
• SInt – Signed 8-bit integer, storing values from -128 to 127.
• UInt – Unsigned 16-bit integer, storing values from 0 to 65,535.
• Int – Signed 16-bit integer, storing values from -32,768 to 32,767.
• UDInt – Unsigned 32-bit integer, storing values from 0 to over 4 billion.
• DInt – Signed 32-bit integer, storing a much larger positive and negative range.

Notice how each of these types differs not just in the size of the number it can hold, but in whether it allows negative numbers at all. If a PLC variable is defined as an unsigned type but the actual process value can legitimately go negative, such as a temperature reading below zero or a differential pressure that can swing in either direction, the SCADA system may misinterpret that value entirely. Similarly, if a smaller data type such as an 8-bit integer is used for a value that can realistically exceed 255, the number will simply overflow or wrap around, producing a displayed value that bears no resemblance to the real process condition.

Why the #### Display Happens

The #### symbol that sometimes appears on a SCADA screen instead of an actual number is not a random glitch. In most SCADA and HMI software, this symbol is a built-in way of saying "the value I received does not fit into the display format I was configured to show." This often happens when the SCADA tag has been set up expecting a certain data type or a certain number of digits, but the underlying data being received from the PLC does not match. It could be because the data type is different than expected, because of a scaling mismatch, or because the raw data being read is fundamentally incompatible with how the SCADA tag was configured to interpret it.

Rather than displaying a wrong or misleading number, the software essentially refuses to guess and shows #### as a visual signal that something is misconfigured. While this is at least a clear indication that a problem exists, it can still be frustrating for operators and confusing for anyone trying to troubleshoot the system without understanding what is really happening behind the scenes.

Why This Problem Happens So Often in Real Projects

One of the underlying reasons this issue shows up so frequently in real industrial projects comes down to how the work is divided. PLC programming and SCADA configuration are frequently handled by different people, sometimes from entirely different companies or departments. If the details of each variable, its data type, its scaling, its address, and its format, are not clearly and explicitly documented, each person involved may end up making their own assumptions about how the data should be structured.

The PLC programmer might choose a data type based on what feels natural for the logic they are writing, without necessarily thinking about how that value will later be interpreted on the SCADA side. Meanwhile, the SCADA configuration engineer might set up a tag based on a general expectation of what the value should look like, without directly confirming it against the PLC program. These two independent assumptions do not always line up, and the mismatch often does not become obvious until commissioning, when the system is finally tested end-to-end and unexpected values or #### symbols start appearing on screen.

Good Practices to Avoid These Issues

Fortunately, this entire category of problems is largely preventable with a few disciplined habits.

Use standard data types. Sticking to commonly used, well-understood data types across a project reduces the chances of confusion and makes the system easier for anyone to review later.

Avoid unnecessary data conversion. Every conversion between data types introduces another opportunity for a mismatch or rounding error. Keeping data types consistent from the PLC through to the SCADA display minimizes this risk.

Create separate data blocks or structures for SCADA communication. Organizing tags specifically intended for SCADA into their own dedicated data blocks makes it much easier to review, document, and validate exactly what is being exchanged.

Clearly document address mapping and data types. A simple, well-maintained document listing every SCADA tag, its corresponding PLC address, and its exact data type removes guesswork for everyone involved in the project.

Check the same data type in both PLC and SCADA. Before assuming a mismatch is a communication error, always confirm that both sides are configured to interpret the value using the same data type.

Test communication using a simulator or OPC client before commissioning. Verifying data exchange in a controlled test environment, before connecting to the real process, gives the team a chance to catch and fix these mismatches early, when they are far easier and cheaper to correct.

Conclusion

A wrong number or a row of #### symbols on a SCADA screen can feel like a mysterious communication failure, but very often the real cause is something much simpler: a mismatch in data type selection between the PLC program and the SCADA configuration. Because PLC programming and SCADA setup are frequently handled by different people, small assumptions about data format can easily diverge without anyone noticing until commissioning day. Taking a few extra minutes early in a project to standardize data types, document address mappings clearly, and test communication before final commissioning can save an enormous amount of troubleshooting time later. In industrial automation, these small details are rarely glamorous, but they are exactly the kind of details that separate a smooth commissioning process from a frustrating one.

 

Understanding OB, FC, and FB Blocks in Siemens TIA Portal: Why FB Really Matters

If you have spent any time inside Siemens TIA Portal, you have seen the Program Blocks folder in the project tree. It usually contains a Main [OB1], a handful of Function Blocks (FBs), a few Functions (FCs), and one or more Data Blocks (DBs). For a student or beginner, this raises an obvious question: since logic can technically be written inside an FC or even directly in the OB, why do we need a separate FB block at all? Is it necessary, or is it just an extra layer of complexity?

 

The short answer is yes, FB is genuinely necessary, and once you understand what each block type is designed to do, the reason becomes clear. OB, FC, and FB are not three interchangeable ways of writing the same logic. Each one has a distinct job in the structure of a PLC program, and using the right block for the right task is what separates a clean, scalable program from a messy one that becomes difficult to troubleshoot as a project grows.

The Organization Block (OB): The Program's Entry Point

Every PLC program needs a starting point, and that is exactly what the Organization Block provides. OB1, commonly called Main, is the cyclic program that the CPU scans repeatedly, over and over, for as long as the PLC is in RUN mode. Other blocks such as FCs and FBs do not run on their own; they are called from inside the OB, either directly or through a chain of calls that eventually traces back to it.

Think of the OB as the conductor of an orchestra. It does not play every instrument itself, but it decides which sections play, in what order, and when. In a real project, OB1 is usually kept fairly clean and readable, calling smaller, well-organized FC and FB blocks rather than containing hundreds of lines of raw logic. This is good programming practice because it keeps the overall program structure easy to follow, even for someone who did not originally write it.

The Function (FC): Logic Without Memory

An FC, or Function block, is the right tool when you need to perform logic that does not need to remember anything between scans. Classic examples include calculations, unit scaling, analog value conversion, comparisons, and common interlock conditions shared across multiple parts of a machine.

The defining characteristic of an FC is that it has no dedicated memory of its own. Every time the FC is called, it executes using only the input values it receives at that moment, produces an output, and then finishes. Once the scan moves on, the FC does not retain any internal state. If you need the same calculation performed for different signals throughout the program, an FC is efficient because it is stateless and reusable without carrying baggage from one call to the next.

This works perfectly for logic like "convert this raw analog value into engineering units" or "compare these two setpoints and output true if the difference exceeds a threshold." There is nothing to remember here; the same inputs will always produce the same outputs, call after call.

The Function Block (FB): Logic With Memory

This is where things get more interesting, and where the beginner's question really gets answered. An FB is used specifically when the logic needs memory, meaning it needs to retain values, states, or conditions from one scan to the next.

Every FB is automatically paired with its own Instance Data Block, often visible in the project tree as something like "Block_2_DB_1" or a similarly named DB directly beneath the FB. This Instance DB is the FB's private memory. It stores internal variables, timer values, previous states, and any other data the block needs to remember across scan cycles.

The motor control example shown in a typical TIA Portal training project illustrates this perfectly. A Start/Stop Motor FB1 block is called with a linked instance data block, and inside it, simple ladder logic uses a Stop contact, a Start contact, and a Motor coil, along with a sealing-in contact that feeds back around the Motor output to latch the circuit. That seal-in contact is exactly why memory matters. Once the Start button is pressed and released, the logic must remember that the motor is running so it stays on. Without a way to retain that state between scans, the motor would only run for the single scan cycle during which the Start button happened to be pressed. That is not how a real motor control circuit is supposed to behave.

Now imagine scaling this up to an actual industrial project with ten motors, each requiring its own start, stop, trip, and feedback logic. Writing this in an FC would not work well because FCs do not retain state on their own; you would have to manually manage separate memory bits for every single motor, which quickly becomes unmanageable and error-prone. With an FB, you simply call the same Start/Stop Motor block ten times, each with its own separate instance data block. The logic is written once, but each motor gets its own independent memory, its own start/stop state, and its own feedback tracking, all without duplicating a single rung of ladder logic.

Putting It All Together

To summarize the roles in the simplest possible terms:

• OB runs the program. It is the cyclic entry point that calls everything else, in order, every scan.
• FC is for logic without memory. It performs a task using only its current inputs and does not remember anything afterward. Ideal for calculations, scaling, and comparisons.
• FB is for logic with memory. It retains internal state through its Instance Data Block, making it essential for anything that must remember a condition across scan cycles, like a latched motor, a sequencing step, or a running timer. 

This is precisely why FB blocks dominate real industrial programming for equipment like motors, pumps, valves, conveyors, compressors, and multi-step machine sequences. All of these devices share one thing in common: they need to remember their current state. A pump that is running needs to stay running until it is told to stop. A conveyor moving through a sequence needs to remember which step it is currently on. None of that is possible with stateless logic alone.

For beginners still getting comfortable with TIA Portal, the best way to internalize this difference is to build the classic Start/Stop Motor circuit inside an FB, call it multiple times with different instance data blocks, and observe how each instance behaves completely independently. Once you see ten separate motors running from one block of reusable logic, each with its own memory, the purpose of the FB block stops being an abstract concept and becomes an obvious, practical necessity.

 

Why 4-20 mA Signal Is Preferred Over 0-20 mA in Industrial Automation

Anyone learning PLC and instrumentation eventually runs into a question that seems simple on the surface but actually reveals one of the most important design decisions in industrial automation: why do transmitters send a 4-20 mA signal instead of a more intuitive 0-20 mA signal? At first glance, 0-20 mA seems like the more natural choice. Zero milliamps for zero process value, twenty milliamps for full scale, clean and simple. But this simplicity hides a serious problem, and understanding that problem is essential for anyone who wants to truly understand how field instrumentation communicates with a PLC.

 

 

The Core Problem: Ambiguity at Zero

Imagine a pressure transmitter connected to a PLC using a 0-20 mA signal. The transmitter measures pressure in a vessel and sends a proportional current signal back to the controller. Everything works fine as long as the signal is somewhere between the two ends of the range. But now consider what happens when the PLC reads 0 mA on that input.

What does 0 mA actually mean in this case? There are several possibilities, and the PLC has no way to distinguish between them:

• The actual process value really is zero, meaning there is genuinely no pressure in the vessel.
• The transmitter has lost power and is no longer operating at all.
• The signal cable between the transmitter and the PLC has broken or been cut.
• There is a loose or faulty connection somewhere in the wiring.

 

From the PLC's point of view, all four of these situations look exactly the same: zero current flowing into the analog input. The controller simply sees 0 mA and has no additional information to work with. It cannot tell the difference between "the process is at zero" and "something in the measurement chain has failed." This is a serious limitation, especially in critical processes where a sudden, unnoticed loss of signal could be mistaken for a genuinely safe, zero-value condition, when in reality the system has gone blind.

This ambiguity is not just a theoretical inconvenience. In real industrial environments, cables get damaged, connections loosen due to vibration, and transmitters occasionally lose power due to wiring faults or blown fuses. If a 0-20 mA signal is being used, any of these failures produces a reading that is indistinguishable from a legitimate zero reading. An operator or automated safety system might interpret this as "everything is fine, pressure is at zero," when the true situation could be a dangerous fault condition going completely undetected.

How 4-20 mA Solves the Problem

The 4-20 mA standard solves this ambiguity through a very simple but clever idea: instead of starting the scale at zero current, the scale starts at 4 mA. This means that even when the process value itself is at the very bottom of its range, the transmitter is still required to output a nonzero current.

In this system:

4 mA represents "Live Zero." This is the current output when the actual process value is at zero, but critically, it also confirms that the transmitter is powered on, functioning correctly, and that the wiring loop is intact. The word "live" is key here. A 4 mA reading is not the absence of a signal; it is a positive, active confirmation that the entire measurement loop, from the transmitter, through the cable, to the PLC input, is healthy and working.

20 mA represents "Full Scale." This is the current output when the process value is at the maximum of its measurement range, exactly as you would expect from a standard proportional signal.

Because the scale never uses 0 mA as a valid operating value, any reading of 0 mA on a 4-20 mA loop immediately becomes meaningful in a completely different way. It no longer represents a possible process value at all. Instead, it becomes an unambiguous fault indicator.

What the PLC Can Now Understand

With a 4-20 mA loop in place, the PLC's logic becomes far more powerful. If the input signal ever drops below 4 mA, the PLC can immediately conclude that something is wrong in the measurement chain, whether that is a broken cable, a transmitter that has lost power, a loose terminal connection, or some other wiring fault. This is a completely different diagnosis than "the process value is genuinely zero," and it allows the control system to respond appropriately, whether by triggering an alarm, switching to a safe fallback mode, or alerting maintenance staff that a field device needs attention.

This single design choice, shifting the zero point of the signal up to 4 mA, transforms a simple analog current loop into something closer to a self-diagnosing communication channel. The PLC does not need any additional wiring, extra sensors, or complex diagnostic hardware to detect these common fault conditions. The information is built directly into the nature of the signal itself.

Why This Matters for Industrial Reliability

Industrial processes often involve critical parameters like pressure, temperature, level, and flow, where an undetected sensor failure can lead to serious safety risks, equipment damage, or costly downtime. Using a signal standard that can silently fail and still appear to report a valid reading is not acceptable in these environments. The 4-20 mA standard directly addresses this weakness, which is exactly why it has become the dominant standard for analog instrumentation across nearly every industry, from oil and gas to water treatment, power generation, food and beverage, and manufacturing.

Beyond fault detection, the 4-20 mA standard also has practical electrical advantages. Current signals are far less susceptible to voltage drop and electrical noise over long cable runs compared to voltage-based signals, which makes them well suited to the often lengthy wiring distances found in industrial plants.

Conclusion

For PLC and instrumentation students, this concept, though it may seem small, is genuinely fundamental to understanding real-world industrial control systems. A 0-20 mA signal introduces a dangerous blind spot at zero, where a real process value and multiple types of equipment failure all look identical to the controller. The 4-20 mA standard eliminates that blind spot by reserving 4 mA as a "live zero" that confirms the health of the entire measurement loop, while 20 mA marks the top of the process range. Any reading below 4 mA becomes an immediate, built-in fault signal.

This is precisely why 4-20 mA has become the trusted backbone of industrial instrumentation. It is not just about measuring a process value; it is about measuring it in a way that also tells you, with confidence, that the measurement itself can be trusted.