Ethernet Comes with a Brand New Easy Solution: Single Pair Ethernet (SPE)

Ethernet is well known globally as solution for communication. Ethernet was hated and liked for the last 40 years or so ... there have been alternative solutions developed that were marketed as much easier, faster, deterministic, ... think of Tokenbus (IEEE 804), Profibus, ... and many others.

Now we see a new version: Single Pair Ethernet (SPE). SPE can bring fast Ethernet (up to 1 GBit/s) and power to the field level using just one twisted wire pair ... enabling application of protocols using TCP/IP.

Click HERE for a general description.

Click HERE for a nice presentation by IEEE experts (January 2019)

SPE is a new technology to replace CANbus in automobiles (cars, trucks, busses, ... trains) and fieldbusses. SPE is a layer 1 standard ... so it can be used for Profinet, Ethercat, ... and it could run TCP/IP.

SPE is more intended to replace fieldbus systems ... here my dream of the late 80s becomes true:

Fieldbus Standardization - Another Way to Go

http://blog.nettedautomation.com/2017/05/tsn-fieldbus-standardization-another.html

additional posts related to the topic:

http://blog.nettedautomation.com/search?q=another+way

The use of SPE for connecting sensors to the cloud is to follow a trend ... it may increase the sales of component manufacturers.

When I wrote my Diploma Thesis in 1982 (at Siemens) I was asked to analyze Ethernet ... the idea was cancelled because of the very very expensive MAU ... needed two ... each for 23,000 USD ... total of 46,000 USD ... no way to get approval to spend that amount for a "standard" Diploma Thesis ... 

It took some 40 years to get to SPE - likely the real Ethernet ... ;-)

Too late for me ... just retired this year with 67 ... 

One crucial challenge is here: HOW to SECURE a huge number of end nodes (sensors, actuators ...) directly connected to the clouds or data lakes? Compare the situation with Smart(er) Grids: In Smart(er) Grids it is intended to connect millions of smart meters to the entities (clouds!?) that use the data for billing and further applications like controlling millions of inverters or power users. 

In the German power system there is a requirement to use the so-called Smart Meter Gateway (SMG) to provide highly secure communication channels! 

Click HERE to check what has to be implemented ... many published Megabyte pdf documentation of the required specification like: "Protection Profile for the Gateway of a Smart Metering System (Smart-Meter-Gateway PP)" ... by the German BSI.

It took many years before we have seen the first certified Smart Meter Gateway offered at the market. And be aware: The Administration of this infrastructure is very complex and ... far away from cheap and affordable by "everyone".

Many similar huge "security systems" would be required to connect the billions of smart sensors and actuators through Single Pair Ethernet to some centralized entities ... 

SPE is nice - BUT to build secure distributed systems it is required to develop also new security solutions that are as simple as Single Pair Ethernet!!

We have to look at the complete SYSTEM COST - not just at the possibilities of a new physical layers ... the SPE increases the problems of implementing secure systems, because it is easier and cheap to build a huge mashed network of millions of end nodes ... that may not perfectly secured!

Smart Grid Interface Modul (SGIM) supports IEC 60870-5-104, DNP3, IEC 61850 and OPC UA

Smart Grid Interface Modul offered by BeEnergy (Pohlheim/Germany)

The Smart Grid Interface Module (SGIM) is a ready-to-use system to monitor measured electrical values in switch cabinets and cable distribution cabinets. The mechanical design of SGIM is in line with industrial standards and is especially meant to be installed in a 185mm busbar system.
SGIM is built from two main parts: the installation platform and the plug-in unit. The plug-in unit contains all necessary control, communication and measurement functions to provide measured data either to a cloud-based data management system or via standard IEC protocols like IEEE 1815 - DNP3, IEC 60870-5-104 and IEC 61850 as well as industrial protocols like OPC/UA.
The device includes a local web server for the visualisation of the acquired data, the configuration of drivers and communication protocols as well as an interface to the WEB-PLC editor.







Click HERE for more information (Data Sheet).
Click HERE to visit BeEnergy

New Smart Grid Controller with IEC 61850, IEC 61850-5-104, and DNP3

System Corp (Perth/Australia) offers a new very powerful Smart Grid Controller for applications in:

1. Secondary Substation Control
2. Transformer and Asset Management
3. Micro Grid Control and Automation
4. Data Gateway Application
5. IoT and Cloud Service Interfacing

Click HERE for more details.

IEC 61850: Gateway for Cloud Computing and Fog Computing

Cloud computing and Fog Computing is in principle supported by a single gateway offered by HMS:

• Bridges any signal from the process level directly to your own or third party cloud.
• Maps any signal from Modbus, Profibus, ProfiNet, Ethernet/IP, IEC 61850, IEC 61400-25, IEC 60870-5-104 ... to Modbus, Profibus, ProfiNet, Ethernet/IP, IEC 61850, IEC 61400-25, IEC 60870-5-104 ...
• Provides many logic functions AND, OR, Timer, Counter, ... to build applications.
• Has digital Input and Output pins.
• Reads M-Bus.
• Supports Client, Server, Client/Server, Client/GOOSE-Subscription (with or more Server/GOOSE-Publishers), and Sever/GOOSE-Subscription
• What else do you need for simple applications?

Click HERE for more information.

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.