Is Industry 4.0 Really a Revolution? And IEC 61850?

There are so many discussions, concerns, arguments ... Pros and Cons regarding Industry 4.0 or the Fourth Industrial Revolution (4.0, IoT, IIoT, Cloud, Edge, data lake, ...).

The most remarkable statements I have heard are from Mr. Ralph Langner who does not believe that it is a revolution at all ...

"Is Industrie 4.0 actually the 4th Industrial Revolution as touted by it's many proponents. Ralph Langner tackles that question in this 20 minute video from S4xEurope."

Click HERE for the youtube video of his presentation (20 min)

Please find some personal opinions:

Please find a paper discussing the "sprint" versus "marathon" in automation of electric power systems I wrote in 2012 through the following post:

http://blog.nettedautomation.com/2012/03/smart-grids-19th-century-invention.html

Here is part of my experience:

I was (as a 21 year old skilled worker in 1973 ... just married) responsible for maintaining a fire alarm system with 6,000 alarm buttons (from a famous vendor ... full of TTL chips ...). The system stopped almost every night ... I had to drive downhill 60 km ... to switch it off and on and go back home ... I was not skilled enough to do anything serious about it ... just wrote reports to my boss ... he ignored everything ... I quit my job in 1974 and went back to high school in January 1995 and university in 1977 ... 7 1/2 years later I finished university with four kids in 1982 ... went back to that same company ... quit again in 1992 partly, in 1997 completely ...

The most crucial reason to quit in 1992/1997 was: The standardization of industrial communication systems in IEC TC 65 released a myriad of non-interoperable Fieldbusses ... good for selling standards ... very BAD for maintenance people and many others ... can you imagine to be an expert in tens of fieldbusses?!

Check out this post:
http://blog.nettedautomation.com/2017/04/iec-sc-65c-published-5000-pages-of-new.html

Oh my dear ...

I just checked my personal records from the 70s and found the weekly reports of my daily maintenance activities ... spent many days to switch off/on the Fire Alarm System ...

This may happen every hour these days where maintenance people just switch IEDs off and on ... in the hope that it will work after restart.

We need more well educated and skilled experts!!! ... grey hair seniors ...

What's about IEC 61850? Is the introduction of this standard series different compared to the fieldbus standard series IE 61158? Sure ... there is a crucial difference:

MANY Fieldbus standards for ONE application (real-time data exchange) ...

ONE IEC 61850 for MANY applications (real-time, protection, asset data, configuration, engineering, ...SCADA, ...).

IEC 61850 series is quite comprehensive and complex ... Yes. But: it seems to be easier to learn and experience ONE complex standard than to do this for 50+ solutions!! IEC 61850 is not a revolution - it could be used to extend existing solutions ... it provides a new approach that could prevent the proliferation of hundreds of vendor-specific solutions ...

And when it comes to security, there is ONE standard series (IEC 62351) for IEC 61850, IEC 60870-6 (TASE.2), IEC 60870-5-104, DNP3, ... 

IEEE Spectrum July 2018: 6 WAYS IoT IS VULNERABLE

IEEE Spectrum 2018-07 publishes an opinion by Stacey Higginbotham about the vulnerability of IoT devices and systems:

6 WAYS IoT IS VULNERABLE

Here is an excerpt of the six reasons why security for the Internet of Things (IoT) is different from—and more difficult to tackle than—traditional IT security:

1. We’ve raised the stakes by connecting more physical systems and facilities to wireless networks -> Consequences of failure are more dire.
2. IoT security is a special challenge:The adversaries are unlike any we’ve seen before.
3. For traditional IT system, one can count on the software company’s support for a
   set amount of time. What we see: it could be 10 years, 7, 3, 2, or even 0 ...
4. A connected product that generates a small profit may require years of updates, patches, and security evaluations.
5. Many connected devices are built with software, hardware, and firmware that are created
   by different companies and pieced together at the end. It takes only one weak link to create a vulnerability ...
6. Many connected devices live in environments unlike any IT system. In a home, there’s no IT manager to push patches to a connected fridge. And in an industrial setting, patching one machine might cause it to stop working with other equipment on the line.

I would summarize the challenge as follows:

IoT devices and systems require in principle the same attention, efforts and resources like traditional IT systems. The sheer unlimited number of interconnected IoT devices will work securely only if we except to spend much more money than what the market expects!

Or: Today´s solutions will be the problems of tomorrow.

Click HERE for the complete document (1 page).

Next Hype: Do You Know Fog Computing?

Some 30 years ago the hype was: MAP (Manufacturing Automation Protocol). One of the next hype is "Fog Computing".

"The Manufacturing Automation Protocols (MAP) and Technical Office Protocols (TOP) were the first commercially defined and accepted functional profiles. Both arose because of the operational concerns of two large corporations, General Motors and Boeing. lt is generally accepted that MAP and TOP were the forerunners, first in adopting OSI standards and then in developing usable profiles.
lt all started at the end of the 1970s. GM had on its manufacturing plant shop floors some 20 000 programmable controllers, 2000 robots, and more than 40 000 intelligent devices, all in support of its business. The main problem was that less than one-eighth of the equipment could communicate beyond the limits of its own island of automation; the main inhibiting factor to greater integration being the lack of an appropriate communications infrastructure. As devices supplied were mostly vendor-specific, to do a particular job, they were not designed or optimised to intercommunicate or support each other's functions.
GM finally realised the gravity of their situation when they began to evaluate the cost of automation, attributing half the cost to the need for devices to intercommunicate. To resolve the matter a task force was created comprising representatives from GM's divisions and their suppliers, with the objective of developing an independent computer network protocol capable of supporting a true multi-vendor environment on the shop floor. They used the OSI model and standards as a basis for interconnection and development of further enhancements. " (Source: The Essential OSI, NSW Technical and Further Education Commission 1991)

The first MAP Profile was published in 1982, Version 1.0 in 1984, MAP 3.0 in 1988. Long time ago!

The MAP approach was understood by just a few experts. Most people believed that MAP was too complex, too ... The fieldbusses were thought as the solutions that could cover a kind of Mini-MAP and realtime communication. MAP passed away and hundreds of fieldbusses have been developed since the late 80s. The result was that myriads of automation islands hit the factory floor. These islands where bridged with OPC and so on ... Now we write 2016! Is there anything new?

Not that much. We still have the problem that the sheer unlimited number of (usually raw) signals (measurements, status, settings, ...) are polled or pushed from the sensor and actuator level all the way up to the SCADA level or even higher. This approach of signal acquisition does not scale in the future where we expect thousand of times more devices, sensors, controllers, ... as GM had to manage in the 70s. Does the Cloud Computing solve this challenge? It is unlikely that this (more or less raw data acquisition) will work?

And now? What to do? Use Fog Computing!

"Fog computing is the missing link to accelerate IoT.  It spans the continuum from Cloud to Things in order to bring compute, control, storage and networking closer to where the data is being generated.

The sheer breadth and scale of IoT solutions requires collaboration at a number of levels, including hardware, software across edge and cloud as well as the protocols and standards that enable all of our “things” to communicate. Existing infrastructures simply can’t keep up with the data volume and velocity created by IoT devices, nor meet the low latency response times required in certain use cases, such as emergency services and autonomous vehicles. The strain on networks from cloud-only or cloud-mostly models will only get worse as IoT applications and devices continue to proliferate.  In addition, the devices themselves are starting to become smarter, allowing for additional control and capabilities closer to where the data is being generated." (http://www.openfogconsortium.org/about-us/#frequently-asked-questions)

Quite interesting that the hype Cloud Computing is seen from a different perspective in 2016.

The approach of IEC 61850 (starting in 1998) is from the very beginning the same as discussed in the Fog Computing community: Compute, control, store, and networking closer to where the data is being generated (at THE process level like in substations or power generation all over). Many information models standardized in IEC 61850 and IEC 61400-25 define distributed functions like protection, active power control or reactive power compensation ... schedules for tariffs, alarming, tripping, reporting by exception (RBE), ... in order to reduce the needed bandwidth and allow for realtime and near realtime behavior.

Lesson learned: Fog Computing is already practiced in the domain of power automation - and based on well defined standards (IEC 61850 and IEC 61400-25)! Both standard series make use of the most crucial standard of MAP: MMS (Manufacturing Message Specification, ISO 9506). It took some 30 years for more people to understand the challenges! ;-) There is nothing new under the sun.