11.2017 Issue
103
ISSN 1470-5745
T h e J o u r n a l o f I n d u s t r i a l N e t w o r k i n g a n d I o T
Rise of cloud connectivity drives smart factory
Common Industrial Cloud Single-pair balanced Interface for CIP data 12 Ethernet transmission 30
IIoT best practices using MQTT architectures 33
Fast roaming challenge 42 for industrial WiFi
www.iebmedia.com/ethernet n www.iebmedia.com/wireless
8
Open road to a common goal: Your Y our Industrial IoT future future
POWERLINK and OPC UA TSN The seamless solution for integrated connectivity. Efficient, vendor-independent, optimized for fast cycle times and structured access to big data. Let's shape the future. www.ethernet-powerlink.org
GET CONNECTED…
www.iebmedia.com/ethernet n
www.iebmedia.com/wireless
Contents
Rise of the Cloud Lost in all of the hyperbole about the Industrial Internet of Things and Industry 4.0 is the rise and importance of cloud computing. Earlier this year, Oracle Corporation published a research study that showed that 62% of businesses are currently implementing robotics technology, or are planning to do so. More than 60% have or plan to work with Arti�cial Intelligence. Most companies also realize that a reliable cloud infrastructure is required to bring these technologies to life. Again, 60% believe an enterprise cloud platform provides the opportunity for organizations to capitalise on innovation such as robotics and arti �cial intelligence. And believe it or not, a large majority of businesses are on-course with their plans to establish a single integrated cloud model across their organization. The Oracle study went on to say that, “while only 8% currently have an integrated cloud model in place that works for legacy applications and new platforms, 36% say they are implementing one in 2016 and another 40% expect to do so in 2017. Only 5% have no plans in place to make this transition.”
• On page 12, we take a look at the Common Industrial Cloud Interface and how it leverages cloud technologies to provide consumers and producers the most value throughout the entire lifecycle of devices that use CIP technologies for data transfer. • On page 26, you can learn how next generation software-de �ned networking is transforming Wide Area Networks. • And on page 38, we look into how fog computing and cloud technology are actually working together to provide more power for control centres. In the world of automation and control, there is no question that network connectivity has become the focal point of technology initiatives. And the cloud in all of its various incarnations is becoming squarely at the center of future plans. We hope you continue to look at the Industrial Ethernet Book as your source for information on these key topics. That is certainly our goal, as we strive to serve our readership and their plans to make the IoT and Industry 4.0 vision a reality.
4
Automation data leverages cloud connectivity architectures
8
Common Industrial Cloud Interface for CIP data transfer
12
POWERLINK and CODESYS enable Industry 4.0 solutions
18
Future-oriented communication for setting up machine networks
20
Cloud-based, cellular SCADA system for water treatment
22
Gigabit Ethernet addr addresses esses requireme requirements nts of Industry 4.0
24
Next generation software-de �ned Wide Area Networks
26
Open architecture enables edge-computin edge-computing g applicatio applications ns
28
Single-pair balanced Ethernet transmission for IoT application applicationss
30
IIoT best practices: guidelin guidelines es for MQTT architectures
33
Industrial web-based computing: is data intelligence intelligence �nally here? 38
This issue is �lled with perspectives on cloud computing and its bene�ts. • On page 8, you’ll find how Cloud communication architectures are providing options for enabling IoT applications by integrating connectivity with �eld level devices. IoT gateways and controllers that offer intrinsic cloud connectivity are combining with OPC UA to provide powerful, secure and � exible exible solutions.
Industry news
C o n t e n t s
Fast roaming: a challenge for industrial Wi-Fi application applicationss
42
New Products
45
Private Ethernet
50
Industrial Ethernet Book The next issue of Industrial Ethernet Book will b e published in January/February 2018 Deadline for editorial: December 21, 2017 Deadline for artwork: January 12, 2017
Product & Sources Listing All Industrial Ethernet product manufacturers (not resellers) are entitled to free of charge entries in the Product locator and Supplier directory sections of the Industrial Ethernet Book. If you are not currently listed in the directory, please complete the registration form at www.iebmedia.com/buyersguide/ to submit your company details.
Update your own products If you wish to amend your existing information, login to the Editor section www.iebmedia.com/buyersguide/register.htm and modify your entry. Do you want to receive issues of Industrial Ethernet Book? Call, mail or e-mail your details, or subscribe at www.iebmedia.com/service/
[email protected] Editor: Al Presher,
[email protected] [email protected] Contributing Editor: Leopold Ploner,
[email protected] Mediaagentur ur Ploner,
[email protected] Advertising: map Mediaagent Tel.: +49-(0)8192-933-7820 · Fax: +49-(0)8192-933-7829
[email protected] Online Editor: Adela Ploner,
[email protected] Circulation:
[email protected] subscriptions@iebmed ia.com
Published by IEB Media, Bahnhofstrasse 12, 86938 Schondorf am Ammersee, Germany ISSN 1470-5745
Al Presher 11.2017
industrial ethernet book
3
s w e n y r t s u d n I
IIC consortium testbeds provide real-world IIoT deliverables Testbeds enable members to think through innovations, test new applications, processes, products, services and business models to ascertain their usefulness and viability before taking them to market. THE FOLLOWING IIC TESTBEDS have shared important �rst results. Track & Trace Testbed: Initially formed to trace process tools, the team deployed sensors that provided information about the location of tools and assets in use. It was expanded from tools to logistics equipment and forklifts. Results: The testbed identified standardization opportunities in localizationtechnology interfaces, tightening-tool interfaces, enterprise-system interfaces, data models, data communications and device management. It also identified reusable interfaces that opened the solution to components from different vendors. Time Sensitive Networking Testbed: Timesensitive networking (TSN) enhances Ethernet to bring more deterministic capabilities to the network, including time synchronization, which schedules traf �c � ows ows and manages central automated system configuration. This testbed applies TSN technology in a manufacturing system with a wide range of automation and control vendors. Results: The testbed deployed early-phase IEEE 802.1 and IEEE 802 Ethernet standards. The testbed will improve upon those standards, making the use of TSN where it can improve ef �ciency, such as manufacturing and energy. Manufacturing Quality Management Testbed: This testbed will improve manufacturing quality by retro�tting outdated factories using modern sensory networks and analytic technologies. The initial success was shown using the welding section of the air conditioner production line in a factory. Results: In March 2017, an optimized noise detection analytic engine was proven to help reduce the false detection rate by 45%. In June 2017, the analytic engine for noise detection was integrated into the production line and the accuracy of pass/fail detection was dramatically improved. Communication and Control for Microgrid Applications Testbed: A microgrid combines generation and storage into a local power system. It allows more reliable use of renewable sources like solar or wind power in conjunction with, or even isolated from, the rest of the power grid. Near-term N ear-term uses are for limited areas, such as a campus, corporation, hospital, factory or residential area. Someday, the microgrid architecture will enable deeper use of renewables throughout the main grid. Results: This testbed proves the viability
4
C I I : E C R U O S
The Manufacturing Quality Management testbed is focused on improving manufacturing quality by retro � ttting ting outdated factories using modern sensory networks and analytic technologies.
of a real-time, securely distributed control architecture for real-world microgrid applications. It leverages an Industrial Internet Reference Architecture (IIRA) pattern called the “layered databus” that federates multiple connectivity domains into a larger system. The testbed implemented the pattern with the Data Distribution Service (DDS) standard as explained in the Industrial Internet Connectivity Framework (IICF) guidance. The testbed validated both the pattern and its implementation, contributing to the Open Field Message Bus (OpenFMB) design, now a power industry standard. INFINITE Testbed: The INternational Future INdustrial Internet TEstbed (INFINITE) uses software-de�ned networking to create virtual domains so that multiple virtual domains can run securely on a single physical network. Results: This testbed enabled intelligent route planning for ambulances to improve response times, leading to better pre-hospital emergency care experiences and outcomes for patients. It also led to improved safety and effectiveness of �rst responders in emergency situations, especially in harsh environments. A third use case enabled detection of anomalies or fraudulent behavior within the power grid through machine learning algorithms. Condition Monitoring and Predictive Maintenance Testbed: This testbed provides
insight into the health of critical assets. It leverages advanced sensors that automatically predict equipment failure and noti�es a person or system so that pro-active steps can avoid equipment damage and downtime. Results: This testbed demonstrated how to make older assets smart, collecting asset health data from four pump/motor skids used to pump chilled water from an HVAC system. Smart Factory Web Testbed: This testbed networks a web of smart factories to improve order ful �llment by aligning capacity across production sites. Results : Factory assets can be registered and searched for in the Smart Factory Web (SFW) portal. IEC standards OPC UA and AutomationML are used to achieve semantic interoperability and are applied to exchange information between engineering tools. The IIC reviews testbed proposals to identify goals, value, potential partners and commercial viability of each testbed. The testbeds must offer a solid business case and have relevance to IIC IIoT frameworks to help members develop IIoT systems more rapidly. The full report, “Why We Build Testbeds: First Results” is available on the IIC website at http://www.iiconso http://www.iiconsortium.org/test-beds.htm. rtium.org/test-beds.htm. News from Industrial from Industrial Interne Internett Consortium. Consortium.
industrial ethernet book
11.2017
s w e n y r t s u d n I
Microsoft demonstration walls highlight Azure Industrial IoT Microsoft partners with Hewlett Packard Enterprise (HPE), Honeywell, Mitsubishi, Rockwell, Siemens, Schneider, Beckhoff, Harting and Leuze showing the Microsoft “Connected Factory”. OPC FOUNDATION HAS DELIVERED the first “Azure IoT Suite Connected Factory” demonstration walls that will be displayed internationally at the Microsoft Technology Centers. These interactive walls demonstrate vendor devices from different verticals showing a bidirectional connection to Azure: • Device-to-Cloud (D2C): (D2C): Devices push telemetry data to the Azure IoT platform • Cloud-to-Device (C2D): (C2D): Allows secure browsing of rich OPC UA information model from Azure IoT platform and “command and control” machines Microsoft first demonstrated OPC UA integration into Azure IoT Suite at Hanover fair in April 2016. Over 30 companies participated by providing OPC UA enabled devices for an integrated Connected Factory demonstration. This Hanover demonstration was later turned into a decision by Microsoft and the OPC Foundation to actively promote the Connected Factory demonstration by developing freestanding OPC UA demonstration walls. The Connected Factory demonstrates the OPC UA technology as a solution for Industrial IoT, Industrie 4.0, Made in China 2025, Korea Manufacturing and other initiatives. Jason Zander, Corp. Vice President Microsoft Azure said during the opening ceremony c eremony of the
C P O : E C R U O S
A purpo purpose se of of the the Azure Azure IoT dem demons onstrat tration ion wall is to to illust illustrate rate devi device-t ce-to-cl o-cloud oud and clo cloudud-to-d to-devic evice e conne connectiv ctivity. ity.
Microsoft Innovation Center in Taiwan: “We see OPC UA as a critical standard for ensuring interoperability between manufacturing processes and equipment, spanning decades of investment for many companies. We have been working with the OPC Foundation on building up 40 OPC UA devices walls which are currently being distributed to the Microsoft Executive Briefing Center in Redmond, worldwide
Microsoft Technology Centers, the IoT Labs in Redmond, Germany and China and the newly established IoT Innovation Center in Taiwan, to demonstrate the strong ecosystem with connected OPC UA devices and the Connected Factory precon�gured solution running on the Azure IoT platform.” News by Microsoft and and OPC Foundation.
Integration of IO-Link into OPC UA THE IO-LINK COMMUNITY has founded a technical working group for specifying the integration of IO-Link into OPC UA based on existing use cases. The Industry 4.0 platform sees OPC UA as a suitable architecture model for implementing integration of IT on the �eld level. This is why a corresponding standard for a data and function model is being developed within the framework of the IO-Link community so as to accurately represent future IO-Link Devices and IO-Link Masters in OPC UA. This approach follows the general recommendat recommendation ion for developing OPC UA Companion Standards. Over the past few years, IO-Link as a pointto-point protocol for sensors and actuators has been able to solidly establish itself and increase its presence. It is manufacturer independent (and thus �eld bus independent), has come to support more than 4,500 devices and enjoys steadily increasing acceptance. Through the use of corresponding logic, so-called “IO-Link Masters”, IO-Link sensors
6
C P O : E C R U O S
A � nal nal proposal for the companion speci � cation cation is to be available before the end of 2018.
and actuators can be connected to the various different �eld bus systems without further adjustment. Such masters can even be economically integrated into simple devices today. IO-Link offers access to a very broad range of sensors and actuators in a standardized way and �eldbus independent. As Industrie 4.0 efforts progress, it is also necessary to semantically incorporate IO-Link
Devices into systems on a higher level than the �eld bus in order to evaluate sensor data. This functionality is often designated as a “sensor to the cloud” to express that sensor data is analyzed by IT systems outside the automation process. In this way, sensor data can also be seamlessly linked to MES and ERP systems. Foundation. News by OPC Foundation.
industrial ethernet book
11.2017
One network, all options Make the most of all the options offered by your Ethernet network. !"## %& '(()* %+,-.
Industrial Ethernet components from Phoenix Contact offer you more real time, more wireless, more security, and more availability. Integrate industrial Ethernet components from Phoenix Contact with ease into your automation infrastructure and benefit from our many years of experience.
For additional information call +49 5235 5235 3-0 0 or visit phoenixcontact.com
ION05-17.000.L1 © PHOENIX CO NTACT 2017
s y n g o i o t l a o c n i l h p c p e A T
Automation data leverages cloud connectivity architectures Cloud communication architectures are providing options for enabling Industrial Internet of Things applications by integrating connectivity with �eld level devices. IoT gateways and controllers that offer intrinsic cloud connectivity are combining with OPC UA to provide powerful, secure and �exible solutions. S N E M E I S : E C R U O S
CLOUD COMPUTING and the Internet of Things promise interesting possibilities for industrial companies by enabling enterprise solutions from process design to new business models. A key prerequisite is a suf �ciently wide database transmitted from the �eld level to the cloud. But this also requires a powerful, secure and � exible exible communication architecture.
Big Data algorithms So the idea is to transmit sensors from the �eld level which, for example, monitor temperature curves, vibrations and power consumption of a machine, to the virtual evaluation platform, the cloud, as the basis for big data algorithms. algorit hms. Direct connectivity of sensors to the cloud via the Intranet and Internet, though, seems rather difficult in practice. Many sensors today are not even Ethernet-enabled; instead they transport the measured values to a programmable logic controller (PLC) via a current interface (4...20 mA). Modern sensors may offer an IO-Link interface, which is also not cloud-capable, and therefore must �rst be compiled into the corresponding protocols including a routing capability by means of a master module and a gateway. Even if the sensor system came with the necessary Ethernet interfaces and protocols, several thousand Internet connections from the �eld to the cloud would be very difficult for IT administrators to control, not to mention the vast amounts of data without a clear business case that would have to be processed in the cloud.
Effective system architectures It therefore makes more sense to provide an aggregation unit on the control level that compresses the data and bundles the information from the large number of sensors. From the automation point of view, this task can optimally be carried out by a PLC, since most of the sensor data accrues there anyway, e.g., for machine monitoring. In addition, the PLC already performs its own compression, e.g., through logical or arithmetic linking of the data. In order to realize the communication from the PLC to the cloud, there are basically two approaches with speci�c advantages. On the one hand, IoT gateways can be used. These devices possess two logical units for data
8
Cloud connectivity requires a powerful, secure and � eexible xible communication architecture.
acquisition and communication to the cloud. The acquisition part is used to cyclically query the data to be transmitted from the field level, primarily from the PLC. The Ruggedcom RX1400 industrial IoT gateway from Siemens, for example, offers the Simatic S7 protocol, which allows the query of data without prior adaptation of the automation program, an effective solution for existing plants. For other device types, the RX1400 also supports OPC UA on the �eld level. So that besides using Ethernet, the data can also be transported via WLAN. For transmission to the cloud, the gateways support various communication protocols, e.g., for the connection to MindSphere. Furthermore, gateways are useful with regard to the security of the communication networks, since the cloud connection can take place via a separate
network path. As an alternative, controllers can also offer intrinsic cloud connectivity connectivity.. Although the automation project has to be adapted in the process, the possibilities are much more diverse. For instance, information about the context of the cloud data is available in the PLC, whether a machine is starting up, is operating normally or is in standby. Derived from this, different data can then be transmitted, or the cycle time for the transmission be dynamically adjusted – tight time periods during startup, rather sporadic status reporting in standby mode. This helps reduce the communication load and avoids flooding the cloud with irrelevant information noise. For these reasons, MindConnect FB technology provides corresponding communication blocks for the
industrial ethernet book
11.2017
y g o l o n h c e T
S N E M E I S : E C R U O S
SIMATIC S7-1500 PLC and the MindSphere operating system, which are con�gured and programmed in the TIA Portal. This also means that the engineering data for the cloud connection is automatically contained in the project backup and can be duplicated on other controllers, an important advantage for manufacturers of standardized machines.
Importance of security Security against attacks remains of utmost importance when it comes to intrinsic communication. Although the MindConnect FB library already features an encrypted transmission of data, the use of a separate communication module is recommended for maximum security, such as the CP 1543-1. This plug-in module for the SIMATIC S7-1500 decouples the cloud communication from the automation network as it provides a separate Ethernet interface. To fend off attacks on the CP, a �rewall is integrated into the module. Denial of service attacks (DoS attacks) on the automation network can also be averted. In addition to the actual communication architecture, the information design has to be considered as well; put simply, this means the protocols to the cloud. From the perspective of a data analyst, proprietary data formats for devices or manufacturers are to be avoided at all costs to avoid complex normalizations in the cloud. Furthermore, it is important to also transport the semantic context of the PLC data to the cloud, i.e., the identi�er, the data type and the location in the object model. Only in this way can a failsafe connection be realized, and with little effort. To this end, a common language in the
Variations for cloud connectivity include MindConnect FB and CP 1543-1 (left) or an industrial IoT gateway (right).
Companion speci�cations
IIoT is required, which preferably is supported by all devices in the same way. The Uni �ed Architecture of the OPC Foundation (OPC UA) offers the best conditions for it. OPC UA is non-proprietary, can be deployed on a variety of hardware platforms and operating systems, offers comprehensive services ranging from dynamic exploration of a device interface to powerful security functions and, above all, is supported by a broad alliance of manufacturers. S N E M E I S : E C R U O S
As a comm common on lan langua guage, ge, OPC UA can can inte integrat grate e all all leve levels ls of of the the IIoT IIoT..
10
A fundamental integral to the success of OPC UA, though, are industry-speci�c and application-speci�c supplementary standards, so-called companion speci�cations. This is where manufacturer consortia or industrial associations together with the OPC Foundation formulate speci�c versions of OPC UA to really make the different devices or applications interoperable. An example is a temperature probe manufacturer which can, of course, integrate its own object model into the sensor. But Bu t what is the symbolic name: “Temp”, “Temperature”, or just “t”? Is the value output in degrees Celsius, degrees Fahrenheit, or Kelvin? Is it an integer or a floating point value? Determinations of this kind are made in the companion speci�cations; only then does OPC UA become truly IoT-capable. One such companion specification was developed for AutoID devices (RFID or optical codes) by manufacturers such as Siemens and Harting together with the OPC Foundation. At the 2017 Hanover Messe, the OPC Foundation demonstrated the interoperability between the Simatic RF600 RFID reader and a device from another manufacturer. The development of these supplementary standards, though, is relatively complex and requires a group of manufacturers that jointly pushes forward the work. It will therefore still take some time until comprehensive OPC UA modeling for all devices and objects of a factory becomes available. Markus Weinländer, Product Manager, Siemen Siemens s.
industrial ethernet book
11.2017
Engineer a Better Network Introducing the industry’s first field-hardened SDN-enabled Ethernet switch. Today’s power system engineers need the convenience of Ethernet combined with low latency and fast healing to support mission-critical substation applications. The SEL-2740S Software-Defined Network Switch and SEL-5056 Software-Defined Network Flow Controller provide an innovative solution that employs software-defined networking (SDN) to enhance en hance the dependability dependability,, performance, configuration, and management of proactive OT and dynamic IT networks. Engineer a better network—it starts with the SDN-enabled SDN-e nabled SEL-27 SEL-2740S. • With failover failover times of less than 100 microseconds, ensure the performance of mission-critical applications under all conditions. • Simplify the design, testing, testing, and implementation of critical power power utility and industrial OT networks n etworks by using the SEL-5056 SEL-5056 Flow Controller Controller.. • Strengthen cybersecurity through through deny-by-default network network access control. control. • Seamlessly integrate with existing network infrastructure infrastructure through OpenFlow 1.3 standard support.
Order your evaluation system to see the advantages of SDN SD N for yourself. For details, visit www.selinc.com/betternetwork .
y g o l o n h c e T
Common Industrial Cloud Interface for CIP data transfer The goal of ODVA’s Common Industrial Cloud Interface is to leverage cloud technologies to provide consumers and producers the most value throughout thro ughout the entire lifecycle of devices that use CIP technologies for data transfer. A V D O : E C R U O S
The three main architectural components in the Common Industrial Cloud Interface reference architecture are CIP Device, CICI Gateway and the Cloud.
THE INDUSTRIAL INTERNET OF THINGS (IIoT) is bringing new technologies, challenges and opportunities to industrial automation. Companies are looking to the internet and cloud computing to provide new ways to improve operations, increasing productivity and generate more revenue. Acquiring data from devices is a primary focus of IIoT in the market today, but there are de �nitely opportunities to do more. What are the challenges presented by these relatively new applications? What technologies are being leveraged to solve these challenges? What capabilities are needed to allow CIP devices to provide an advantage in these applications?
that were previously unavailable, starting with the ability to connect to devices across an enterprise or a machine type across multiple enterprises. In addition, the ability to scale computing power and storage are enabling new possibilities for analyzing data streams. In the sections below, we will highlight some of the basics of cloud computing and explore a set of Information exchange patterns that are common to all applications that include devices, gateways and cloud. As an overview, the three main architectural components in the reference architecture are CIP Device, CICI Gateway and the Cloud.
CIP devices Introduction A new Special Interest Group (SIG), the Common Industrial Cloud Interface (CICI), is grouped under the Optimization 4.0 banner among ODVA activities. Its goal is to develop standards that enable new cloud applications to be developed by the member community leveraging the rich data available in devices that conform to ODVA standards. The new SIG intends to leverage “cloud technologies” available today and “connect” them with the rich information de �ned in CIP Devices in a simple and secure manner. The objective is to focus on making available means to discover CIP devices and the data available in those devices, along with also looking for opportunities to manage devices and collections of devices through gateways. Cloud computing offers many advantages
12
In the context of CICI reference architecture, a device is a CIP-enabled device connected to a CIP enabled network. The CIP device’s purpose doesn’t change within the CICI context, nor do its characteristics or behaviors. This statement is very important to consider when contemplating the role of the CICI Gateway and Cloud as well as the guiding principles spelled out later in this article. Only conceptually does the CIP-enabled Device change. In the CICI Reference Architecture, a CIP Device engages in an extended, much wider architectura architecturall context that includes the Cloud. In this wider architectural context, a CIP Device’s data (telemetry, etc.) can be published (indirectly) to the Cloud, to be processed, stored and analyzed by services and applications executing there. Likewise, commands and
noti�cations can originate from those same cloud-based applications and be pushed back down through the CICI Reference Architecture to CIP Devices. This is made possible because of the CICI Gateway. No changes to a CIP Device are required for it to interoperate within the CICI Reference Architecture. Architecture. CIP Devices in CICI reference architecture are decoupled from the Cloud; all integration requirements are handled by the CICI Gateway. This important requirement enables full CICI interoperability for legacy CIP Devices.
CICI gateway A CICI Gateway is a middle-tier architectural component that is physically located on-premise and that logically bridges between the CIP network and the Internet and Cloud. Logically, it has two logical interfaces: downstream connects to the CIP-enabled network and n-number of CIP Devices; upstream connects to the Internet and Cloud. As a middle tier CICI Gateway maintains contextual information for n-number of CIP Devices on its downstream interface. On its upstream interface, it maintains context (e.g. security credentials, endpoint URIs, etc.) of multiple Cloud-based services, messaging systems. A CICI Gateway performs a number of roles, most visibly bi-directional secure routing of Device-to-Cloud (D2C) and Cloud-to-Device (C2D) messages between CIP Devices on its downstream interface and Cloud-based services and apps on its upstream interface.
industrial ethernet book
11.2017
A V D O : E C R U O S
y g o l o n h c e T
The diagram above shows the Telemetry Information Exchange pattern used in conjunction with the Common Industrial Cloud Interface (CICI) reference architecture.
A CICI Gateway translates and normalizes message payloads as they pass across the domain boundaries of CIP and the Cloud. This crucial operation satis �es a core guiding principle: CIP stays home. Logically, a CICI Gateway can be implemented at the level of a CIP Device, e.g. a CIP Device performs its own CICI Gateway functions. This approach is a two-tier, device direct to cloud connectivity pattern and is not recommended.
Cloud In the CICI reference architecture, the Cloud is the Public Cloud. Technically, the public cloud is a complex collection of cost effective, scalable, geographically distributed infrastructure, infrastructu re, software and platform services. Conceptually, however, the Cloud should be thought of in simpler terms: as the data collection, processing and analytics platform on which value will be created for the next generation of CIP customers. Value for CIP customers is provided by actionable information which can be used to make asset management and business decisions. Actionable information is derived by the CIP Device related data. Once collected, processed and analyzed, this data results in the ultimate value for ODVA customers: actionable asset information. Cloud-based applications will also consume raw CIP Device data as well as the derived actionable data. Deriving actionable data is the ultimate goal of CICI since this is generally where value is provided to customers. For example, high levels of value to customers due to cost reduction can be achieved in the area of asset maintenance. As device monitoring is increasingly understood and analyzed, maintenance action can evolve from costly run-to-failure (reactive), to more ef �cient preventive (proactive) to the most cost effective, predictive.
Public Cloud Computing This section introduces ‘Cloud Computing’ concepts as related to CICI, so that readers can
14
share a basic understanding of this complex technical landscape. Public Cloud Computing, aka ‘the Cloud’ or ‘Cloud Computing’, represents a signi �cant, disruptive shift from traditional information technology (IT) and software product creation and delivery. In some cases, the Cloud will compete directly with an existing technological model, such as with on-premise hosted Data Center, potentially displacing it. In other cases, the Cloud should be seen, not as a competitive or displacing force to existing technologies, such as CIP, but as a complementary extension and enabler for developing new and different types of applications and solutions which leverage existing technologies. Irrespective of it being a competitive or complementary force, Cloud Computing is disruptive to both technology and business models and brings significant risk for companies and industries attempting to adapt. The simple reason for this is that modeling and implementing Cloud-based solutions such as IIoT is complicated and multi-dimensional. This is not just a question of technology, but extends to business models, the increasing emphasis of OPEX over CAPEX, dif �culties with costing imprecision, and the reformation of sales channel and revenue stream, etc. The �rst big challenge is that the Cloud Computing marketplace evolves daily and presents a bewildering and expanding set of choices among technologies, service offerings, service costing models and vendors. Secondly, the landscape of public Cloud vendors is complex and confusing: small, medium and large vendors compete for business in general purpose and specialized niche service markets. Finally, because of the rapid evolution of the Cloud there is no single path for successful Cloud adoption for a company or even its individual lines-of-business. However, for companies and industries that are able to navigate these complications and can adapt to and leverage the Cloud’s capability new possibilities emerge for developing customer value and driving
business opportunity. Cloud Computing offers companies extensive infrastructure, platforms and software services that traditionally have been available only at the corporate, enterprise or data center infrastructural level. These service groupings are referred to as ‘as-a-Service’ resources and are as follows: Infrastructure-as-a-Service Infrastructureas-a-Service (IaaS) (IaaS) is is a selfservice model for using storage, servers, networks and related virtual resources. The user of the service is usually responsible for managing applications, data, con�gurations, licensing and updates of related resources, including in some situations, the operating system. Resources usually have a number of options for performance and quality of service levels and can be very cost effective. A common use of IaaS is for hosting, networking, load balancing and storage for applications. Platform-as-a-Service (PaaS) (PaaS) is vendor managed platforms and middleware on which vendor applications and solutions can be rapidly developed, tested, operated and maintained. Messaging middleware, integration frameworks, databases and business process management are common PaaS services. These services are rapidly leveraged and require no maintenance. Similarly, to IaaS services, PaaS services offer a choice of service level and/or are billed per a consumption-based subscription model. Common uses of PaaS are the deployment of non-monolithic services, integrating decoupled components in a distributed system, storing of quantities of information at Big Data scale and deploying analytics algorithms. Software-as-a-Service (SaaS) is software deployed in the Cloud, yet accessible virtually anywhere by clients. SaaS represent representss the large and growing �eld of cloud-based application services and offers as well as new architectural concepts such as microservices. SaaS applications are often accessed via thin-clients such as Web Browsers and mobile applications (native or hybrid) and, therefore, generally require very limited downloaded installation components or none at all. A common use
industrial ethernet book
11.2017
A V D O : E C R U O S
s n o i t a c i l p p A
The Inquiry Information Exchange pattern using the reference architecture.
(and ultimate goal) of SaaS for vendors is to use it as a platform for deploying products and solutions which include capabilities that are simply not possible with traditional on-premise deployment: Big Data analytics; geographic redundancy; IoT-level scalability; and world-wide access. Cloud computing has introduced, or at least raised to a high degree of public awareness, many new technologies and concepts. Big Data describes data sets of magnitudes and complexities never seen before. Big Data implies analysis of these data sets using specialized tools, algorithms programming languages and technologies to discover trends and patterns which may be used to drive business value. Data sets are characterized by the ‘Four Vs’, described below.
Four Vs of Big Data The Four V’s of Big Data are Volume, Velocity, Variety and Veracity. Volume: Represents the scale of the data sets. One hears of systems running at ‘Big Data Scale’, which implies that they can consume and process data sets of unimaginable size. Technologies been built exclusively to address the need to scale with the many orders of magnitude expansion of storage needs. An example of this is NoSQL databases, which can scale to Big Data scale in IoT systems, replacing SQL databases which cannot. Velocity : Represents the ubiquitous and persistent collection and delivery of data, from consumers, sensors, systems into cloud-based Big Data oriented-systems. Variety : Represents the ability to combine dissimilar data sets which previously could not have been combined are now being processed together. The Cloud enables the combination of public and private data to provide insights previously unattainable. Tweets, traffic, weather, Facebook, stock prices postings are examples of well-known dissimilar data sets which could be combined and analyzed
16
to provide previously unattainable analytic JSON outcomes. JSON, JavaScript Object Notation, is a terse, Industrial examples of public/private data readable, structured data format. It is very sets are current power costs, impending popular as a payload format for Device-toweather events, raw materials cost, motor/ Cloud and Cloud-to-Device messaging. A machine/plant ef �ciency metrics, etc. bene�t to using JSON is that many stream Veracity : Represents the fact that much processing applications are built to natively of Big Data information available is of consume JSON structures efficiently and questionable quality. cost-effectively. Below is a very basic JSON Inaccuracy of data in consumer-based Big message: Data applications is a challenge, requiring { cleansing and validation processing and “name”=”CICI”, assessment. It may not pose such a challenge “message”=”Hello World!” in more tightly managed and audited } Industrial environments. Nevertheless, it must be accounted for. Guiding principles or concerns As we apply cloud technology and cloud NoSQL communication patterns to use cases, a NoSQL is a database model/approach which number of concerns have been identified. has evolved during the Big Data era and which These concerns form the basis for guiding contrasts markedly with Relational Database principles to be applied to any resulting work. Management Systems (RDBMS or SQL): NoSQL The technical, semantic and application databases have relaxed or non-existent difference between cloud-based and CIP referential integrity requirements, flexible Device-based ecosystems is vast. The purpose storage options and limitless scalability and of CICI is to de�ne an integration approach redundancy built in from the ground up. The to bridge between the two environments so acronym NoSQL originated from ‘non SQL’ and/ that cloud-based applications (and application or arguably ‘not only SQL’. developers) can consume CIP Device data and produce actionable information useful to the AMQP CIP Device, directly or indirectly. It is not the AMQP, Advanced Message Queuing Protocol, is purpose of CICI to replicate the CIP networkthe open standard and has emerged as a very based ecosystem in the Cloud but to abstract popular protocol for sending messages to and and represent CIP Device data so that its use receiving messages from Cloud-based systems. by Cloud applications is simple and ef �cient. In addition to being open and standard, The following are some of fundamental AMQP was designed with these characteristics differences of Cloud-based from CIP-network Security, Reliability, Interoperability. based application development: Distribution:: Cloud-based applications are Distribution MQTT intrinsically distributed, combining resources MQTT, Message Queue Telemetry Transport, from multiple compute, storage and service is an ISO standard (ISO/IEC PRF 200922), platforms to achieve function. Real-Time:: due to its distributed nature Real-Time publish/subscribe, lightweight messaging protocol used for Cloud-connectivity for and platform dependencies, the notion of limited network bandwidth and remote real-time is an uncommon concept in public cloud computing. applications. industrial ethernet book
11.2017
Protocols and Payloads: Payloads: Cloud-based application developers expect message payloads that are easily programmatically digestible, potentially extensible for business process purposes and normalized to contain meaning for a given application domain, such as Asset Management analytics. Abstracting CIP details satis�es these expectations while exposing CIP protocol or payload formats would cause lost productivity for developers, potentially large, incremental, pro�t impacting unmarshalling/marshalling unmarshalling/m arshalling costs. Applications:: Cloud-based applications have Applications very broad scope and virtually no limitation to the types of functions that can be performed. Cloud-based applications can be modified and updated very rapidly (in minutes, hours) and often integrate multiple streams of information simultaneously to produce results. Communications between entities on the cloud are generally based on widely used open standards which are not industry speci �c and which may be replaced at any time. CIP communications, while standardized, are industry speci�c and slow to change. Developer Pool: Pool: Cloud developers master a variety of programming languages, ‘cloud oriented development’ and cloud architectures that are very different from those needed by CIP network application developers. Abstracting CIP details with a normalized Device Asset domain model, for example, greatly increases the pool of potential developers for CICI-based Cloud applications. In order to not compromise security of on-premise resources, CICI Gateways and CIP Devices are not exposed the internet by publicly available interfaces such as publish/subscribe broker or http web service endpoints. Device-to-Cloud and Cloud-toDevice communications are through an established CICI Gateway. For example, to support Cloud-to-Device communications, Cloud applications send messages to devices indirectly through Cloud-based egress queues to which the CICI Gateway subscribes. All communication must be performant and scalable across a variety of networks. This means that CIP must “stay home” or stay on premise where responses are timely and consistent. Any solution identified should avoid a speci�c implementation, but instead be described in general terms. On one hand, this document avoids recommending implementation technologies. Instead, the focus is on D2C and C2D information exchange patterns common in the solution marketplace and relevant to the design of CICI and CICI-based solutions. On the other hand, some technologies (AMQP, MQTT, JSON, etc.) are included in typical CICI architectures to illustrate how contemporary IIoT/Cloud integration are achieved and relate to information exchange patterns important to CICI. 11.2017
Information exchange patterns Four Information Exchange Patterns generalize the logical patterns of communication that will occur between the cloud and gateways or devices. Telemetry Telemetry is one-way, with information � owing owing that a device or gateway “volunteers” to a collecting service, either on a schedule or based on particular circumstances. This information represents the current or temporally aggregated state of the device or the state of its environment, like readings from sensors that are associated with it. Telemetry is initiated by the CIP Devices based on a previous con�guration or runtime subscription request. Data � ows ows from the CIP Device to the CiCi Gateway and sent to the Cloud to be available for Cloud applications. Note that security had been omitted for simplicity, but the connection to the cloud would be set up before data would begin to � ow ow following a Telemetry Information Exchange pattern. The exchange pattern is one way, so that the CIP Device does not expect a response from the Cloud application. Inquiry With inquiries, the device or gateway solicits information about the state of the world beyond its own reach and based on its current needs. An inquiry is a singular request, but might also ask a service to supply ongoing updates about a particular information scope. A vehicle might supply a set of geo-coordinates for a route and ask for continuous traf �c alert updates about particular route until it arrives at the destination. Inquiry is initiated by the CIP Device and � ows ows through the CICI Gateway to the Cloud application via its messaging endpoint. The Cloud application receives the Inquiry message and creates a response. The Cloud app then sends the response message to the Egress queue to which the CICI Gateway is subscribed. The CICI Gateway routes the message to the correct Device. The Inquiry exchange pattern differs from Telemetry in that a response or acknowledgement from the Cloud application is expected. Of note is the use of Correlation IDs in the messaging between the CICI Gateway and the Cloud application. Correlation ID is an Enterprise Integration Design Pattern used to relate a response to the correct request in asynchronous, non-guaranteed ordered communication scenarios. Noti cations � cations Noti�cations are one-way, service-initiated messages that inform a device or a group of devices about some environmental state they’ll otherwise not be aware of. Wind parks will be fed weather forecast information and
industrial ethernet book
cities may broadcast information about air pollution, suggesting fossil-fueled systems to throttle CO2 output or a vehicle may want to show weather or news alerts or text messages to the driver. Notifications are initiated by the lineof-business Cloud applications. Cloud apps send Notification messages to the egress queue to which the CICI Gateway has subscribed. The CICI Gateway then routes the noti�cation messages to the appropriate CIP Device or group of devices. The Noti�cation exchange pattern is the logical inverse of the Telemetry exchange pattern and, therefore, the Cloud application does not expect an acknowledgement or response from the device.
T e c h n o l o g y
Commands Commands are service-initiated instructions sent to the device. Commands can tell a device to provide information about its state, or to change the state of the device. That includes, for instance, sending a command from a smartphone app to unlock the doors of your vehicle, whereby the command �rst � ows ows to an intermediating service and from there it’s routed to the vehicle’s onboard control system. Command is initiated by the line-of-business Cloud application. Command messages are sent to the Digital Twin or directly to the egress command queue to which the CICI Gateway is subscribed. The CICI Gateway sends a synchronous request to the CIP Device and relays the response to the Cloud endpoint. Command is the logical inverse of Inquiry. Therefore, the Cloud application expects a response from the Device. Once again, the Correlation ID enterprise integration pattern can be leveraged for correct message logical routing and processing of responses.
Next steps This article covered new technologies that are being introduced into the industrial automation marketplace. It provides a “�rst pass” de�nition of one of the communication patterns and an example of how that communication pattern could be realized. It can be easily observed that the Common Industrial Cloud Interface work is just getting started. There is a lot of ground to be covered to completely define the remaining three communication patterns at a high level. The next steps will be to fill in more details, referencing all the technologies and standards available and keeping in mind the guiding principles enumerated. But the goal is to leverage cloud technologies to provide consumers and producers the most value throughout the entire lifecycle of devices. Stephen C. Briant, Technology Manager for Rockwell Automation and Thomas Whitehill, Remote Services Architect, Schneide Schneiderr Electric Electric .
17
y g o l o n h c e T
POWERLINK and CODESYS enable Industry 4.0 solutions New technology tools have been developed that enable i ntegration of POWERLINK Industrial Ethernet technology into the CODESYS IEC 61131 6 1131 development environment. These innovations enable manufacturers to deploy control systems already working in CODESYS as a POWERLINK master. G S P E : E C R U O S
Integration of POWERLINK in CODESYS: The POWERLINK Con � �guration uration Editor from BE.Services is a plug-in for the CODESYS IDE. The CODESYS I/O driver is embedded in g
the runtime system and accesses the openPOWERLINK stack. Any device that can be written via XDD � lle, e, whether I/O module, sensor or actuator, and can be integrated into the POWERLINK network.
THE CODESYS DEVELOPMENT ENVIRONMENT is often used by small and medium-sized manufacturers of control systems but the amount of programming work that has been required for POWERLINK integration, until now, has been prohibitive. To combine the two technologies, a POWERLINK software module has been developed that enables use of this real-time protocol as a POWERLINK master, and creates user advantages including high performance, noise immunity and openness.
18
Solution overview The technology includes a package of software and services that consists of four components: a user-friendly, visual con �guration editor for POWERLINK in the form of a plug-in for the CODESYS development environment; an extension to the CODESYS runtime system in the form of an I/O driver for the openPOWERLINK stack; servicing and integration services as well as an e-learning course for POWERLINK technology. Like the CODESYS IEC 61131 development
environment, the POWERLINK plug-in is available free of charge from the CODESYS store. An I/O driver is available for a buyout price and includes support services and a license for the BE.educated e-learning platform. The �rst pilot customers are already using these products in development projects. For the large number of component and control system suppliers already working with CODESYS, POWERLINK is a viable option. All of these manufacturers can now use their control systems as a POWERLINK master and
industrial ethernet book
11.2017
benefit from its real-time performance in their automation solutions. The POWERLINKCODESYS master will be tested at the upcoming POWERLINK plugfest, with a goal to certify POWERLINK products that will work together on both the slave and the master side. The BE.services software package has been integrated to provide advanced functionality and includes the ability to con�gure master and slave parameters, as well as device-speci �c parameters. This information is obtained from the standardized device description files (XDD) provided by product manufacturers. In addition, there is support for advanced POWERLINK functions such as poll response chaining, cross-traf �c and modular devices. Linux is generally used as the operating system, preferably with a real-time extension. But openPOWERLINK can also be used without an operating system, or with Windows. Potential applications for the POWERLINK/ CODESYS combination range from the automation of individual machines, to production lines or entire factories. Mobile automation and process control systems are also possible areas of application. The source code for the openPOWERLINK stack is available under the BSD license free of charge from SourceForge. The stack is entirely software based and completely scalable; it can be deployed on an FPGA or an x86 system, so
The POWERLINK �guration Con � g uration Editor can be used to con � g �gure ure master and slave devices. Applicat Appl ications ions can be written in the CODESYS IDE using any IEC 61131-3 language.
users can choose their hardware platform. Moreover, the open-source approach provides investment protection. That’s becoming an persuasive argument, especially in this time of disruptive business models. The CODESYS implementation also offers key advantages for new designs as well.
CODESYS implementation Within CODESYS, fieldbus and industrial Ethernet communication modules are generally implemented using IEC 61131 languages, which are by nature slower than a native porting. The openPOWERLINK stack is modular and is available in C++. It can therefore be
compiled directly on the hardware platform and bene�ts from FPGA hardware acceleration. In collaboration with the OPC Foundation, the EPSG has also developed a companion specification that enables data to be exchanged between OPC UA and POWERLINK. Users get the benefit of POWERLINK’s performance at the machine level, as well as the bene �ts of OPC UA TSN as the future standard for communication at the controller level and into the cloud. Dr. Christoph Gugg, Technology Manager, Ethernet POWERLINK Standardization Group and Dimitri Philippe, CEO, BE.services BE.services..
Uptime. Anywhere. Your track to high-speed networking
Industrial IP67 Managed Gigabit Ethernet Switches with PoE+ Red Lion’s versatile NT24k-16M12 managed switches feature 16 all-Gigabit copper M12 X-code ports and is housed in a dust proof and water resistant IP67-rated enclosure. The NT24k-16M12 is designed to provide reliable operation in railway and other industrial applications subject to shock, vibration and other extreme conditions. POE budget con�gurable across all 16 ports, the Bypass relay ports enable data to continue to �ow even in the event of a power outage, making this an ideal choice for rail applications. Visit www.redlion.net/Nt24k to learn more. Hall 8 - 327
+31 (0) 33 4723-225 I
[email protected] I www.redlion.net © 2017 Red Lion Controls, Inc. All Rights Reserved.
T e c h n o l o g y
s n o i t a c i l p p A
Future-oriented communication for setting up machine networks The growth of larger and larger automation networks is overtaxing the machine builders’ ability to manage their networks. With the high amount of time needed for effective deployment rising and costs escalating, more and more companies are looking for a solution that simpli �es network management. SEAMLESS ETHERNET-BASED DATA EXCHANGE from the field level to office applications is one of the central challenges that Industrie 4.0 presents to future machine networks. Communication specialists, therefore, needs to offer appropriate solutions that are not only comprehensive, but also easy to handle, secure and ready for the future. Whether man or machine, one thing is certain; without communication, nothing works. However, in the practice, it frequently happens that participants do not understand each For secure connections between the machine and production network, tsecurity appliances provide extensive � rewall rewall functions that other, or not correctly. protect the machine network against unauthorized access Reasons include many participants speaking High-availability networks at once, different languages or complex supplemented with new technologies. And all ways of expressing themselves. It is a fact of that has to stay manageable for both their In the past, unmanaged switches usually and the customers’ employees. that misunderstandings can easily cause served as interface between the network errors with unforeseeable consequences. participants in machine building. The Therefore, a uniform language and regulated Uniform control philosophy reasons included their low price and easy communication are fundamental prerequisites To meet these demands, new device types are startup. However, these devices cannot meet for trouble-free information exchange between used in the machine networks, in addition to the demands that arise from the growing all participants. And that also holds true for switches that connect the components and communication needs of the constantly the data exchange in machines and systems. control the data transmission. For example, increasing number of network participants. In the past, the amount of Ethernetto connect mobile end devices or transport For example, unmanaged switches have capable components was still relatively systems to the automation network, wireless no mechanisms for network diagnostics or limited, but thanks to the universal Ethernet modules are used. Security components are reducing data load. Therefore, they can only communication, their number is continuously increasingly used to ensure safe integration be used in modern machine networks to a increasing. As a result, the risk of unwanted of the machines into the production network. limited extent. data traf �c on the network also increases. Additionally, they allow encrypted and secure On the other hand, intelligent switches Unauthorized devices that are connected or remote access to the machines. In machine have precisely these functions. Thanks loops that are accidentally established can building, the pressure to be competitive on to optimally matched functionality, they interfere with the production process. If the the global market is high. combine the advantages of the easy operation user then additionally needs special protocols, To answer the demand for devices that of unmanaged devices with the powerful such as PROFINET or EtherNet/IP, the devices are easy to handle, it makes sense to source capabilities of the managed switches. The used have to ful �ll special requirements to all the required network components from a new FL Switch 2000 product family of Phoenix safeguard reliable data exchange. single manufacturer. This allows a uniform Contact additionally supports redundancy Technology trends such as cloud-based control philosophy and creates leeway for mechanisms for loop suppression, as well solutions, IT security, the use of smart price negotiations. With the FL Switch 2000, the essential functions of the PROFINET devices or the possibility of secure remote FL WLAN 1100, FL mGuard und TC Cloud Client and EtherNet/IP transmission standards. maintenance also influence the network product families, Phoenix Contact therefore An innovative Unmanaged Mode ensures communication. For machine builders, this provides a diverse set of solutions for the user-friendly handling. It allows the device means that they constantly have to plan special requirements of modern machine to be operated as unmanaged switch, while and service larger networks that can be management functions for stabilizing the requirements.
20
industrial ethernet book
11.2017
T C A T N O C X I N E O H P : E C R U O S
network are active in the background. With the FL Switch 2100 models, it is additionally possible to set up machine networks for gigabit communication.
Reliable wireless technology The trend to integrate mobile devices and driverless transport systems into the machine network makes wireless data communication essential, for example using WLAN. To ensure that the data is reliably transmitted to the receiver, an access point that sends out a WLAN signal should be installed at the respective machines. Usually, the access point is installed in the control cabinet and at least two antennas are mounted on the machine. With the FL WLAN 1100 product family, Phoenix Contact has created an easy solution for full WLAN reception at machines and systems (�gure 2). The wireless module not only unites an access point and antennas in one device, but, with a little work and using a single-hole mounting method, can also be installed directly on the machine, on the control cabinet or on a mobile vehicle – even as retro �t. The two antennas integrated into the access point support all customary WLAN standards (IEC 802.11a/b/g/n) and frequencies (2.4 GHz and 5 GHz), as well as the MIMO antenna technology (Multiple Input Multiple Output). This ensures fast and reliable data transmission.
Secure remote access Connecting the machine to the production network, integration into a cloud-based solution or remote maintenance by the machine builder: regardless of the application, secure and therefore encrypted communication is crucial. The remote maintenance modules of the TC Cloud Client and FL mGuard product families make it possible for service personnel to remotely connect to the machines and systems via the Internet. Depending on what is needed, this connection is either established via the operator’s networks, or via the global 4G LTE mobile network. The mGuard Secure Cloud makes it possible to set up a scaleable VPN infrastructure with encryption by means of the IPsec security protocol. This safeguards the con�dentiality, authenticity and integrity of all exchanged data. For secure connections between the machine and the production network, the FL mGuard security appliances additionally provide extensive firewall functions that protect the machine network against unauthorized access.
Easy con�guration Many machine builders prefer using devices that are easy to operate in their networks. T o avoid the additional time and costs involved in con�guring more complex components, the machine builders make conscious decisions to 11.2017
forfeit the advantages of a robust, diagnosable network. As mentioned above, unmanaged switches with plug-and-play capabilities are frequently used. These simply have to be connected to a power supply and the network. No settings have to be con�gured. To minimize the con�guration work needed for components with management functions, without forfeiting the many bene �ts they offer, the new devices of Phoenix Contact have been optimized for machine building applications and are easy to con�gure. In addition to the con�guration options usually offered, such as web-based management in a browser and SNMP (Simple Network Management Protocol), the switches of the 2000 product family and the TC Cloud Client are equipped with an SD card. With the card, the con �gurations created can be replicated as often as needed. And if the user needs to replace a defective component, the extensive work involved in the initial con�guration need not be repeated for the replacement device. The wireless modules of the FL WLAN 1100 and FL Switch 2000 product families additionally offer the option of con�guration by means of a command-line interface (CLI).
Transparent network management Larger and larger automation networks - this trend is overtaxing an increasing number of machine builders’ ability to manage their networks. Additionally they complain about the high amount of time needed and the resulting costs. As a result, many companies are looking for a solution that simplifies network management. With the FL Network Manager, Phoenix Contact offers a new software tool that encompasses all important functions for managing switches, as well as WLAN and security components from �rst device con�guration and monitoring functions during live operation, to user-friendly con�guration and �rmware management. In the past, it was necessary to perform firmware updates on each individual device. With the FL Network Manager, it is now possible to update all components simultaneously. simultane ously. The device con�guration in the network is just as easy. All con�guration �les can be saved locally with a single step, to then be loaded onto a (replacement) device when needed. Integrated BootP/DHCP and TFTP server functions eliminate the need to use several different tools to con�gure the device parameters. The FL Network Manager thus unites all important management functions for an automation network into a transparent tool. Ja n Au le nb nber er g, M. Sc Sc., ., pr od uc uctt ma na ge r for net wor k tec hno log logy, y, Phoenix Contact Electronics GmbH.
industrial ethernet book
21
s n o i t a c i l p p A
Cloud-based, cellular SCADA system for water treatment Systems integrator Perceptive Controls has designed a cloud-based, cellular SCADA system for rural water and wastewater treatment systems. By using a RESTful API, developers gained secure, programmatic access to data from new or legacy physical assets wired to a programmable automation controller. 2 2 O T P O : E C R U O S
Using its Polaris software and a SNAP programmable automation controller-based system, Perceptive Controls was able to deliver a low-cost SCADA system that avoids expensive servers and hardware while still providing the monitoring, control, alarming, and reporting functions that water and wastewater plant operators require.
LIKE PLANTS AND PEOPLE, cities need water to grow. The average American’s daily use of water reaches upwards of 100 gallons. Major cities like New York, Chicago, and Los Angeles need billions of gallons of water per day. And when people turn on their faucets, they expect the system that delivers their water to just plain work. In reality, a lot more goes into delivering clean, potable water than most people realize. Transporting water and wastewater throughout municipalities is a complex task that requires significant investments in advanced SCADA technology. But not all water districts have the budget to acquire the necessary technology.
The challenge Modern water and wastewater treatment regulations require water districts to maintain systems for monitoring, data acquisition, alarming, and reporting on the quality of water delivered to residents. While large cities can afford the technology investments required to transport billions of gallons of water per day, smaller water districts, often located in remote and rural areas, can struggle to �nd the budget required to implement a modern SCADA system. Instead, processes remain manually driven
22
and as a result are prone to errors that can lead to a system failure. The rugged and remote location of many rural water districts can also pose a challenge in implementing a SCADA system. Most modern municipal water systems use some form of wireless technology, often 900 MHz radios, to establish a SCADA network between remote sites. These radios are a good solution for SCADA networks because they operate in an unlicensed spectrum and do not require a service provider network to relay data from site to site. However, in rugged terrain it can be dif �cult to obtain the direct line-of-sight connection 900 MHz radios require. Cellular connections are often the next best option to establish a SCADA network between remote sites. But the data charges associated with cellular connectivity can be cost-prohibitive, due to the scan-based poll/ response communication architecture of traditional SCADA systems. Recognizing the needs of smaller water and wastewater treatment plant operators to add affordable SCADA systems to their operations, systems integrator Perceptive Controls developed a cellular, cloud-based SCADA system called Perceptive Polaris to overcome these challenges.
The solution Using Perceptive Polaris software with an Opto 22 SNAP PAC control system, Perceptive Controls was able to deliver a low-cost SCADA system that avoids expensive servers and hardware while still delivering the monitoring, control, alarming, and reporting capabilities water and wastewater plant operators require. One of the key challenges engineers at Perceptive Controls faced during development of the solution was how to reduce the amount of data sent between lift station sites on the SCADA network. “We knew that using cellular modems meant one of the most important requirements of this project would be the ability to transmit the smallest data packets possible, with as much data in each packet as possible,” said Kevin Finkler, software engineer for Perceptive Controls. “We had to stay under the data caps of the cellular provider we planned to use.” “Our original design was to use a script running on an Opto 22 PAC-R2 controller,” added Finkler. “The script would collect data from municipal equipment and perform an HTTP POST to transmit the data to a cloudbased server we host for our clients. The server is where our Perceptive Polaris software application resides.” During evaluation and testing of the �rst
industrial ethernet book
11.2017
2 2 O T P O : E C R U O S
Lift stations can be monitored in real time, with map overlays to give operators real-time situational awareness.
version of the system, posting large amounts of data from the controller to the cloud server proved to be slow and processor intensive. In addition, the cloud server didn’t have a reliable method for ensuring con�guration changes, such as HMI setpoints, were sent back to the controller. “This posed a problem,” said Chris Parish, senior application engineer at Perceptive Controls. “The controller would often check for con�guration changes, only to have the server respond back saying that no changes were needed. It wouldn’t work to have the controller check less frequently, because we wanted the controller to be able to respond in a timely manner.” “We decided to consider alternate options for transferring data. So we investigated the RESTful API capabilities built into Opto 22 SNAP PAC controllers,” Parish added. SNAP PAC controllers come with a built-in, secure HTTP/S server with an open, documented API, effectively creating a RESTful architecture. RESTful architecture and its technologies, like HTTP/S and JSON (JavaScript Object Notation), are intrinsic to the Internet of Things and paramount to web, data, and mobile-based application development. With their RESTful API and secure server, the SNAP PACs offer valuable alternatives for application development. Through the RESTful API, developers can gain secure, programmatic access to data from new or legacy physical assets wired to the PAC.Developers can use any programming language that supports JSON to access control variables and input/output (I/O) data. “After switching to the new RESTful API method, we now have a cloud-based software application running on a dedicated server that uses the SNAP PAC’s RESTful API to request data directly from the controller,” Parish said. “Requests are made over a private cellular network to avoid cyber security-related concerns and avoid opening ports in �rewalls,” Finkler added. “We store data in � oat oat tables on the PAC (about 44 indexes per table) and the software can grab up to 100 tables of data per request without slowing down communication performance.” 11.2017
The cloud application then uses the RESTful API to write back how many tables were retrieved, so the controller can delete the old data and move everything up in the table, with new data again at the top. This ensures that all data was received into the cloud application. “It’s more efficient to make the cloud application process large amounts of data, instead of making the controller do the work in addition to its normal operations,” noted Finkler. “This method saved an average of 5.8 KB per data set transmitted, which ended up saving us about 250 MB per day, adding up to signi�cant savings in cellular data charges.” Using the RESTful API, Perceptive engineers can also send configuration changes on demand. Since con�guration changes rarely occur after the initial setup, 99% of the previous configuration traffic has been eliminated, and data is transmitted only when necessary. The cloud application also monitors for alarms and sends out notifications to operators if necessary. Using the Perceptive Polaris solution, water and wastewater customers can monitor their lift stations and SCADA network in real time, with advanced map overlays that provide operators with real-time situational awareness of the SCADA system. Operators can view and respond to alarms through the website, and authorized users are alerted to alarms via email and/or text messaging. Operators who receive an alarm can acknowledge it by replying to the text message. Historical data is stored on cloud servers hosted by Perceptive Controls and backed up regularly.
Looking ahead The engineers at Perceptive Controls are currently developing a mobile app that will communicate with the Perceptive Polaris server and allow users to respond to alarms and change setpoints as needed. “In the future, the entire SCADA system will be able to be managed from almost any authorized mobile device,” Finkler said. Application article by Opto 22.
industrial ethernet book
y g o l o n h c e T
Gigabit Ethernet addresses requirements of Industry 4.0 Is Gigabit Industrial Ethernet adoption the key to achieving Industry 4.0 goals? While there may still be some debate about what Industry 4.0 really means, there is no denying that greater interconnectivity of devices and increased network capability will be the key drivers behind achieving the goals it sets out. AS MANUFACTURERS EXAMINE FUTURE challenges around low volume production, increased customisation and increased competition, it is easy to understand why the concepts of Industry 4.0 have come to the fore. Industry 4.0, combined with the Industrial Internet of Things (IIoT), not only holds the key to addressing many of these challenges, but also promises to deliver innovations that today’s manufacturers have not even thought of yet. Industry 4.0 can be defined as the combination of “cyber-physical” systems with the IIoT. Underpinning it are Ethernet and Internet-based technologies that provide the connectivity for everything to communicate with everything else, regardless of where a device or system is physically located, or what it actually is. Today, while we talk about high levels of interconnectivity, usually there are incompatibilities in networks that mean projects are divided into separate islands. As we overcome these incompatibilities and drive ever greater levels of integration and interconnectivity, Industry 4.0 will allow production machines to provide more transparency and cooperate to a higher degree. Some say that this will ultimately lead to intelligent factories capable of autonomous production changeovers, reassignment of production equipment and perhaps even scaling their capacity as demand increases. By extension, this will also take in the Internet and collaboration with vendors and customers to a greater degree than is possible now. None of this can happen, though, without the networks to carry the information between the places where it’s needed, in real-time. Ethernet provides a good foundation for this infrastructure, but being able to deliver the necessary performance will require technology with greater capabilities than is common now. CC-Link IE technology, however, is addressing all of these requirements today.
A P L C : E C R U O S
CC-Link IE Field Network topology examples Line topology Master station
Local station
Remote station
Remote station
Remote station
Station-to-station distance: max. 100 m
Overall cable distance: 12000 m
Star topology
Master station
Layer 2 switch
Layer 2 switch
Station-to-station distance: max. 100 m
Local station
Remote station
Local station
Remote station
Remote station
Ring topology Master station
Local station
Remote station
Remote station
Remote station
Gigabit Ethernet in automation One of the key requirements of Industry 4.0 applications is the need to share large amounts of data from multiple devices in real-time. Hence bandwidth is critical to the successful operation of these systems. CC-Link IE offers a performance increase of around 10 times compared to any other
24
Station-to-station distance: max. 100 m Overall cable distance: 12100 m
Support for multiple topologies is important to addressing the need to share large amounts of data in real-time.
industrial ethernet book
11.2017
A P L C : E C R U O S
Ring type wiring
Line type wiring Star type wiring CC-Link IE topologies can be combined together to provide systems that offer maximum � exibility. exibility.
similar protocol today, and offers the highest bandwidth available at 1Gbps, delivering the performance needed to connect the most datahungry processes together. CC-Link IE is based on the Ethernet standard IEEE 802.3, and allows for ring, line and star topologies. In addition, the line and star topologies can be combined together to provide systems that offer the maximum application flexibility. The ring and line connections are particularly attractive, as they permit simple “daisy chaining” of devices, meaning the added cost and complexity of network switches can be avoided.
Addressing cyber security concerns One of the key concerns related to the increasing adoption of industrial Ethernet is cyber security. While the use of Internet-based technologies has increased the possibilities of what can be achieved in manufacturing, it has also increased the threats. Some industrial Ethernet protocols are based on a standard TCP/IP (UDP/IP) stack, which can arguably cause some security vulnerabilities. CC-Link IE combines the physical and data-link layers of the OSI hierarchy with an open protocol that extends from the network to application layers. The result is an open, but controlled knowledge base that CLPA partners are free to implement, but reduces the exposure to unauthorised use. Another concern potential users may have regarding the protocol is its compatibility with TCP/IP (UDP/IP) traf �c. While current network design practice encourages segmentation of networks for security and performance reasons, sometimes it’s still necessary to support non-control related network traf �c. CC-Link IE supports this with the capability to encapsulate TCP/IP (UDP/IP) packets for transmission across the network, allowing this traf �c to “tunnel” through the CC-Link IE system. CC-Link IE technology also allows considerable application flexibility by supporting multiple protocol types on the same network. This reduces costs and increases maintainability. In addition to the standard I/O control, it also offers safety (SIL3), motion control and energy management on the same 11.2017
cable. This allows the CLPA to offer a costeffective, simpli�ed, � at at network architecture that meets the needs of nearly all applications in the discrete sector.
Speed and simplicity When it comes to actually using the network, again, the emphasis is on simplicity. CC-Link IE’s basic communication technique is based on a shared memory model. All the devices on the network occupy an area of the controller’s memory. To communicate with them, it’s only necessary to change the value of the data in the area corresponding to the relevant device. The network automatically handles the traf �c via the standard “cyclic” (synchronous) communication. The same process happens in reverse for communication to the controller from devices. For high priority, unscheduled events such as alarms, or lower priority non-cyclic transmissions such as diagnostic information, an alternative “transient” (asynchronous) communication method is available. The technology has been designed such that even high levels of transient traf �c do not impact the deterministic regular cyclic communication, meaning normal system functions are not impaired and the scan cycle is completely deterministic. Deterministic performance is achieved with a token passing method, allowing dependable system operation. In practice, this allows network update times to occur in a few tens of microseconds, depending on system size and con�guration. CC-Link IE also offers the ability for redundant controllers, so even a controller failure will not necessarily result in lost production. We can see, then, that CC-Link IE technology can help manufacturers reap the bene �ts of greater connectivity across their processes, with improved network performance delivering tighter control, greater data throughput at high speed, deterministic performance and inherent security. It is also set to play a key role as manufacturers push towards models of Industry 4.0 in order to address the production challenges of tomorrow.
Precise and simple! Time synchron synchronization ization using IEEE 1588/PTP
OMICRON Lab IEEE 1588/PTP Timing Solutions: OTMC 100 TICRO 100 www.omicron-lab.com/timing
John Browett, General Manager, CLPA Europe.
industrial ethernet book
!"#$% '("()* !+,-%(+).
y g o l o n h c e T
Next generation softwarede�ned Wide Area Networks Software-de�ned WAN technology leverages and virtualizes multiple types of connections between business locations, as well as connections between data centers, remote of �ces, and cloud resources. SD-WAN also provides a way to leverage broadband Internet while incorporating traditional dedicated WAN technologies. D U O L C O L E V : E C R U O S
Software-de � �ned n ed WAN leverages and virtualizes multiple types of connections between business locations including data centers, remote of � ces ces and the cloud.
SOFTWARE-DEFINED WIDE AREA NETWORKS are becoming the basis for a new generation of WANs for enterprises and service providers. Just as Frame Relay and ATM migrated to MPLS for business connectivity, the combination of SD-WAN, migration to the cloud, and commodity Internet broadband are offering a compelling, affordable and � exible exible option to augment the WAN. The move to SD-WAN becomes imperative as demand increases for business critical, bandwidth hungry real time applications in of �ces and �eld locations.
The traditional WAN Before diving into the new world of SD-WAN, let’s review traditional wide area networks. A WAN traditionally connects a company’s business locations together, creating what’s essentially a single large network that might span multiple locations within a city, locations in many cities, or even locations across national boundaries or around the world. Those businesses might have one or more data centers, and multiple of �ces that have remote workers. The goal is to provide seamless connectivity between remote locations and the applications they reply upon, no matter where those applications are hosted. Workers inside a business location are
26
connected via a local area network (LAN), which is a private, high-speed network, installed, owned and maintained by the business. The LAN can be wired and wireless using technologies like Ethernet and WiFi. Likewise, servers within a data center are also tied together with high-speed LANs. The WAN ties those sites together. By contrast with the high-speed, private LAN owned by the business, WANs are services traditionally provisioned by telecommunications companies. WANs are much slower than LANs, and incur monthly charges based on bandwidth, guaranteed reliability, and the distance between the sites. WANs can take weeks or months to set up, up , and just as long to make make service changes, changes, such as to adding bandwidth to handle new demands. There are many telecommunications technologies used to implement traditional WANs. Older technologies include leased lines, Frame Relay, ATM (Asynchronous Transfer Mode). One of the most popular WAN technologies today is MPLS (Multi-Protocol Label Switching). While MPLS-based WANs run across one or more carriers’ networks using complex protocols, they can be thought of as highly reliable, very secure, point-topoint links between a business’ sites. The
downside of MPLS-based WANs is that they are expensive, slow to provision, and dif �cult to change to adapt to varying requirements. Why not use the Internet for connecting business locations? The Internet is ubiquitous, inexpensive and flexible. However, the Internet is famously unreliable, both in terms of uptime and in the ability to deliver consistent throughput. It’s also insecure, and without additional security, cannot be trusted for intra-business traf �c, such as accessing key business applications, servers or �les. The challenge is that businesses are increasingly frustrated with traditional WANs. IT professionals and executives like that WANs are reliable, predictable and secure. On the other hand, businesses don’t like the monthly expense, slow provisioning times and the lack of � exibility. exibility. They also don’t like that WANs become more complex when the business locations are in different countries. Finally, with the emergence of cloud computing, the traditional WAN falls short architecturally to the needs of the new paradigm.
The SD-WAN World Software-defined WAN leverages and virtualizes multiple types of connections between business locations, including
industrial ethernet book
11.2017
data centers and remote of �ces, as well as connections between data centers, remote of �ces, and cloud resources. SD-WAN leverages broadband Internet while providing the ability to incorporate traditional dedicated WAN technologies like MPLS. SD-WAN is transport agnostic and overlays controls that deliver quality of experience and ensure reliability, predictability, security, manageability, and reduced cost. For example, a company may have several data centers, large of �ces with hundreds of employees, and small field of �ces. It may use cloud-based services for applications, servers, and storage, with a mandate to eventually migrate the bulk of its data centers to the cloud. From the users’ perspective, SD-WAN is a single wide area network that offers trustworthy security, plenty of bandwidth, service reliability, quality of service (QoS) that ensures a good user experience when making calls using Voice over IP (VoIP) or videoconferencing, and seamless access to both data center and cloud applications. From the IT perspective, SD-WAN offers a single interface to manage the wide area network, with the ability to rapidly adjust the services to accommodate new requirements, or to provision new services. However, under the surface SD-WAN takes advantage of multiple types of network connections, including traditional WAN technologies, the public Internet, and even cellular data connections. Demand is escalating for business critical, real time applications such as voice, video and virtual desktop applications. Adding more private circuits for these bandwidth hungry applications is expensive and does not improve cloud application connectivity. A cost effective solution is to leverage broadband public Internet to augment the MPLS links by using SD-WAN. Employees in main of �ces and branches need to access Software-as-a-Service applications. SD-WAN understands the location of those applications, and will d irect user sessions directly to the cloud ef �ciently, using the high quality link for the highest priority applications. This represents a signi�cant improvement over the traditional WAN architecture model, which routes remote employee traf �c over the MPLS network back to a data center and then redirects cloud application traf �c from there to the Internet. This adds delay and consumes unnecessary WAN bandwidth. In short, SD-WAN leverages multiple WAN technologies and other connections, lowering monthly costs, simplifying operations, adding agility, providing full security, and offering end users an exceptional experience. It’s a perfect technology for connecting branch of �ces and even short-term “pop-up” business locations that need to be brought up instantly such as construction sites. 11.2017
Implementing the SD-WAN Generally speaking, SD-WAN is a software control layer that contains a few parts. There is a management tool implemented in a dashboard that provides easy administration by IT professionals, with minimal effort by staff in the �eld location. There is a control plane, that actively and intelligently manages and routes network traf �c over all available communications technologies in accordance with business priorities. And there is a business policy framework, which sets requirements and baselines for security, quality of service, cost controls, user experience and priorities. SD-WAN controls can be located within the business’ data center, but optimally it will be run via the cloud, where it is equally equ ally accessible to all business locations, and where it can be managed as Software-as-a-Service – thereby reducing the workload on corporate IT. Enterprises have options when it comes to choosing SD-WAN. They can contract directly with a provider of the SD-WAN software solution, and implement it using internal staff. For some organizations, that will be the best choice. For others, there are new SD-WAN offerings from major telecommunications service providers, who are adding SD-WAN to their portfolio of WAN offerings. For example, a new AT&T SD-WAN service will let businesses prioritize and route data across their networks based on the performance requirements of the applications. The offering, powered by SD-WAN, will also let businesses better manage their bandwidth. The SD-WAN offering will come in two � avors: avors: a networkbased offering and a premises-based solution. Cloud-delivered SD-WAN technology from VeloCloud, part of this new SD-WAN solution, offers technology for true multi tenancy, automatic link monitoring, auto-detection of WAN and Internet providers and autocon�guration of link characteristics, routing and quality-of-service settings. QoS settings are con�gured based on a database of more than 2,500 applications, and helps determine the best paths for applications based on the business policies set by the cu stomer. In addition, the system provides resilience that goes beyond both the public Internet and traditional MPLS WANs, taking advantage of real-time network performance to ensure that performance-dependentt applications, such as performance-dependen voice and video calling, are given the proper priority – and blackouts, brownouts, and excessive delay and jitter can be remediated quickly, with sub-second responses. For agile businesses, branch office connectivity is not a luxury; it’s businesscritical. SD-WAN introduces enterprise WAN to the cloud era enabling quality of experience, reduction in Capex and Opex while simplifying branch WAN infrastructure. Mike Wood is VP Marketing at VeloCloud VeloCloud .
industrial ethernet book
Machine builders will love our new IIoT product!
!" $% &'()"*%+%& ,./. 0/1 23045. 6,77 8 9 .-,:& ;<= 6,77 <> 9 .-,:& ;8>
!!!"#!$%"&'(
)*!#+$,#
y g o l o n h c e T
Open architecture enables edge-computing applications Fragmentation and vendor lock-in are preventing companies from adopting IoT solutions to remotely manage devices at the edge. There is a need for standard-based, �exible and modular device application frameworks to develop IoT and edge-computing applications. O M R E T S
TECHNOLOGICAL INNOVATION, together with a steady decline of the price of sensors and devices, has led to a constant increase in the number of interconnected interconne cted devices. Billions of devices will reportedly be interconnected in the next years. The fourth industrial revolution, or Industry 4.0, is based on the assumption that devices are becoming smarter, thanks to advanced software applications which allow simple and cost-effective communications among them.
W : E C R U O S
Edge vs. cloud computing Traditional IoT cloud architectures are based on physical assets which collect data and send them to cloud data centers for further analysis. However, for some �eld applications latency is not an option. Data has to be managed at the �eld level and response must be immediate, and cloud computing might not be the best option. There is a need to bring the data center to the �eld. In addition, bandwidth and infrastructure costs become an issue when huge amount of d ata need to be transferred (e.g. via cellular connectivity); Java/OSGi-based building blocks for developing IoT applications. local data management is usually limited to some �ltering, triggering or averages in order to make “distilled” information. Gateway initiative (OSGi) model can speed application development at Reducing system architecture complexity is a key success factor in the IoT edge-device level, as well as offer advanced remote management IIoT applications as well as turning �eld devices into edge computers. capabilities not available through traditional embedded agents. As a They become able to process data and apply intelligence, so that matter of fact, still some of the agents are often constrained on speci �c only the data which have already been analyzed are published to the hardware and mostly hard coded in C/C++, preventing developers to cloud. This simpli�es business applications development and leads to apply changes (they are rarely allowed to access some APIs to set increased productivity. Moreover, bringing IoT application development a few parameters). Those agents cannot ensure advanced remote to the �eld implies that edge computing can reduce the gap between management capabilities. Remote maintenance, over-the-air updates information (IT) and operations technology (OT). and upgrades are dif �cult to perform, and developers often have to Interoperability between the factory and the of �ce becomes possible start from scratch to upgrade the devices. thanks to IoT edge devices that securely connect the service platform At the edge-device level, a more robust and open device application layer with the factory environment. These powerful edge devices, or framework is desirable to enable advanced device management next generation gateways, become bridges for IT/OT communication features. A Java/OSGi-based application development framework that bene�t both layers. IT has a direct and remote access to �eld offers a portable, modular and � exible exible solution to easily communicate processes and devices, whereas OT can interact with data analytics and with cloud-based management platform and develop advanced IoT other advanced applications to optimize production processes. applications for remote monitoring and control.
Java and OSGi for edge computing platforms Even if some effort has been put in place in order to provide some standards and common protocols there are still some barriers that are responsible for slowing down the process of adopting IoT solutions solutio ns such as vendor lock-in and fragmentation. At the edge, “things” connect to �eld machines through sensors, actuators, controllers, agents and gateways. There are numerous cloud platforms for data storage and analysis, and in several cases, each of them has its own communication protocols. Therefore, IoT solutions are usually tied to speci�c vendors, generating deeper fragmentation between IT and OT. Java-based device application frameworks in the Open Services
28
Advanced device management Companies are interested in more advanced remote management capabilities and broad access to a wider range of parameters to control �eld devices. For example, a multi-national manufacturing company would want to remotely access data coming from its plants distributed worldwide, in order to monitor them and perform predictive maintenance and software updates, thus reducing maintenance costs and optimizing the production line. This kind of advanced device management can be achieved with an edge-computing platform, and Java/OSGi is the best way to ensure open standards, modularity, � exibility exibility and a standard interface. industrial ethernet book
11.2017
OSGi is a modular platform for Java that implements a complete component model, providing modularization of Java applications and infrastructure allowing components to communicate locally and across a distributed network with a vendorindependent approach. As a result, developers have access to a coherent IoT services architecture based on speci�cations that are highly scalable for long-term remote management and Visual IoT application architecture for connecting maintenance. As an OSGi deployment bundle, Java-based applications can be remotely managed and easily con�gured. By adding and/or removing new application bundles it is easy get directly into the application management layer. An edge-computing platform deployed this way, by means of its Java/ OSGi-based applications architecture, allows the developers to easily manage various parts of the device from an application standpoint. Developers do not like fragmentation. They prefer to develop and manage their apps in the same way across different edge devices, whether it be a Raspberry Pi or custom-built hardware, it should be managed in the same way. Using a hardware abstraction layer on top of an OSGi-based container and Java Virtual Machine (JVM) simpli�es application development and optimizes portability across systems and hardware architectures. Leveraging a proven architecture and software building blocks that provide extensive services, an edge-computing platform will allow shorter device software development. Once this standard software platform is in place, processing valuable data becomes easier than it has ever been before. Moreover, integrating Eclipse Kura (a Java/OSGi based open-source project for IoT I oT applications development) means preventing vendor lock-in and guaranteeing the protection of the software investment.
Virtualized devices are now ready to be connected to the cloud. This is possible thanks to a Cloud Service API which manages data collected by the gateway and publishes them to a remote server via the MQTT protocol. A store-andforward functionality provides out-of-the-box support for connecting to different IoT cloud providers, allowing the development and deployment of IoT gateway solutions that are not tied to a particular vendor. In addition, the API simpli�es the implementation � eld eld devices to the cloud. of more complex interaction � ows ows such as request/response or remote resource management and offers a policy-driven publishing system to abstract the application developer from the complexity of the network layer and the publishing protocol used. From a security standpoint, the platform offers an extensive security management set of services to provide a secure application execution environment, to reduce risks related to remote management of �eld devices and to simplify the management of certi �cates, keystores, application signing and system integrity. Additionally, a VPN client service allows system administrators to access the devices using a secure VPN connection via Ethernet, Wi-Fi or cellular modems.
T C e c a h s e n o S l t o u g d y y
Technology report by Eurotech. Eurotech.
While you look ahead … we have an eye for the rest.
Simplifying edge-computing application development After providing the Eclipse Foundation with the Kura programming code, Eurotech enhanced it and realized a commercial version for the development of IoT applications at the edge-device level. Basic requirements for effective and integrated IoT applications are: • Connectivity to �eld devices • Virtualization of �eld assets • Connectivity to IoT cloud services The platform simpli �es the communication between the edgecomputing device and the devices by employing a single model: it comes with pre-installed �eld protocols libraries (Modbus and OPC-UA, for instance), so that a common format can be reused across different devices. Thanks to a device abstraction layer, it creates a d igital twin of the device, by providing APIs to connect to I/ O interfaces of an IoT gateway, such as Serial communication (RS 232/485), Bluetooth 2.1 and 4.0, BLE, USB and CAN Bus. The virtualization of �eld devices enables visual development of IoT applications. The Wires programming environment offers a modular data � ow ow programming tool to de�ne data collection and processing pipelines at the edge by simply selecting components from a palette and wiring them together. This way users can, for instance, con�gure an asset, periodically acquire data from its channels, store them in the edge device, �lter or aggregate them using powerful SQL queries, and send the results to the Cloud. Different components are represented as “wired” nodes and added and connected with drag-and-drop, freeing the developer from programming any code. 11.2017
industrial ethernet book
Nuremberg 28-30 November 2017 Hall 9, Stand 231
360° Network Reliability for Smart Factory Automati Automation on • 3 industrial protocols protocols with one-click setup • 2 installation options: options: DIN-Rail and Rackmount • 1-page configu ration dashboard Moxa Solutions. Protected, easy, intelligent.
www.moxa.com
29
s y n g o i o t l a o c n i l h p c p e A T
Single-pair balanced Ethernet transmission for IoT applications The mega trends in communication technologies, and their impact on associated cabling philosophies, are being in�uenced and driven in no small way by the emergence of the IoT, Industry 4.0 (I4.0), cloud computing and smart technologies -- ultimately leading to new connector and cabling solutions. ETHERNET IS THE LEADING NETWORK PROTOCOL in LAN applications and is increasingly gaining ground in new areas. At the start of the Ethernet “era” in the early 1980s, coaxial cabling dominated (thick Ethernet – yellow cable, thin or cheap Ethernet), from the 1990s the focus shifted to cabling solutions based on symmetric cabling (twisted pair) and �bre optics. Initially, twisted pair cabling relied on two-pair cables. This utilized a wire pair as a transmission and reception line (100Base-TX). This principle, limited to a transfer rate of 100Mbit/s, still represents the main transfer principle in industry and automation systems technology today and is often achieved using star-quad cable designs. In order to achieve higher transfer rates of 1 Gbit/s and 10 Gbit/s, a transfer technique was selected, which requires four symmetric pairs in connection with 8-pole c onnectors. Now, let’s discuss the transfer of Ethernet with a single strand pair, in other words, a solution that quite obviously runs contrary to the technical development of Ethernet and its associated cabling. This article deals with the background of these developments, with the technical details and the normative activities as well as the applications for single-pair Ethernet. We consider the performance of new chipsets and discuss the classi�cation of single-pair cabling with respect to existing two and four-pair versions as well as future n-pair cabling.
Mega trends in communications The development of new communication technologies and their associated cabling philosophies, are in� uenced uenced and driven in no small way by the current ICT mega trends, such as IoT, Industry 4.0 (I4.0), cloud computing and smart technologies. This leads to new demand pro �les regarding communications technology and the network infrastructure behind it, based on cables and connectors. Demands include: high availability, short access times including distributed data and fast transport of this data from A to B. Secure transfer of large datasets in different application areas up to determinism (real-time transfer and, for example, guaranteed data transfer within a de �ned timeframe).
30
G N I T R A H : E C R U O S
Overview of co-action of standardization bodies to strengthen cabling guidelines and technology.
At the same time, data transfer should remain cost-ef �cient. For devices, cables and connecting hardware this means they must achieve higher performance, be smaller and stronger as well as possess a high degree of modularity and compatibility (exchangeability and plug-compatibility). These demands can only be fulfilled through innovation, i.e., new development of products with consistent international standardization. Another trend in network technology and cabling is the increasing use of Ethernet protocols in new application areas. This includes many automation protocols and, increasingly, sensor/actuator applications. Numerous traf �c and transport platforms such as rail, tram, bus, ship and aircraft, are �tting their � eets eets with Ethernet. While Ethernet has been successfully employed, in particularly for passenger information systems and for WLAN services for many years now in the methods of transport mentioned above, it remained more or less unused in the private car/truck market for a long time. The automobile industry has now recognized the advantages of Ethernet and started an initiative to develop Ethernet protocols for short-distance transmission
routes in vehicles. The solution is called: single-pair Ethernet for transmission distances up to 15 m or 40 m. This Ethernet technology has since been published in the standards (Gigabit Ethernet over single-pair balanced copper cabling) and 802.3bw 100Base-T1 (100 Mbit over singlepair balanced copper cabling). To achieve simultaneous transmission of data and energy, PoDL was also de�ned under IEEE 802.3bu (Power over Data Lines = a principle suitable for single-pair transmission for remote powering). On the basis of these standards chipsets, devices, cables and connecting hardware are now being designed, developed and produced for integration in private cars. Cabling for private cars focuses on a transmission distance of up to 15 m and, in general, needs to be produced in unshielded form due to weight and spatial constraints. Larger vehicles such as trucks and buses require longer transmission distances of up to 40 m and, due to the associated higher EMC requirements, need to be fully shielded. In fact, the latter single-pair shielded transmission distance also has other “non-automotive” application groups and
industrial ethernet book
11.2017
has piqued the interest of manufacturers. This Cross-section of SPE cable is because, in general, shielded single-pair 1. Conductor: Ethernet cabling offers Uncoated Cu (stranded), AWG26/7 all of the features required to fulfil the 2. Isolation stranding element: mega trend described Cell-PP, wire ø: NW 1.25 mm, pair above. They are fast, 1 space-saving, cheap and 3. Alu-coated polyester polyester �lm, metal-side simple to implement. 2 external (PiMF) For this reason, industry, whose 3 4 Tinned Cu-meshing, optical covering automation profile is approximately 90% now largely based on 4 1000 Mbit Ethernet 5. Halogen, �ame-resistant compound 5 (100BASE-TX), is showing increasing interest in solutions with single-pair New designs offer the ability to transmit Ethernet according to 1000Base T1 over a single-pair cabling channel. Ethernet. In fact, within building automation developers are actively considering the via a 15 m UTP channel (Type A, unshielded) Therefore, a technical report is being different possibilities provided by integrating and a 40 m STP channel (Type B, shielded) prepared under the title “TR ISO/IEC 11801single-pair Ethernet within the hierarchy and is de�ned. Both channels are speci�ed for a 99xy‚ One Pair Channels up to 600MHz”, which structure of contemporary building cabling. bandwidth of 600 MHz, may contain up to four describes shielded single-pair transmission Then there are also numerous other application connections and guarantee a transmission channels. The target applications are the areas, which present attractive opportunities capacity of 1 Gbit/s. so-called “non-automotive” segments or for the development of single-pair Ethernet. IEEE 802.3bu “Physical Layer and Industry 4.0, IoT and smart lighting in the The interest in single-pair Ethernet also Management Parameters for Power over Data style of IEEE 802.3bp. reflects a general trend in standardised Lines (PoDL) of Single Balanced Twisted-Pair These transmission channels allow network cabling, and diversification of Ethernet” bidirectional transfer of 1 Gbit/s by using a structured cabling for specific application Analogously to PoE (Power over Ethernet), balanced pair up to 40 m with simultaneous areas. this also speci �es the parallel provision of energy supply of end devices. ISO/IEC JTC1 SC25 WG3 currently includes energy up to 50 W via single-pair Ethernet The transmission channels typically consist of a permanent link 36 m in length which activities or projects which deal with the channels. realisation and implementation of the ISO/IEC JTC1 SC25 WG3 currently includes incorpo-rates up to four connections and technical results of IEEE 802.3 within activities or projects which deal with the two 2 m long patch cords. This document is structured building cabling. realisation and implementation of the scheduled for completion in 2018. technical results of IEEE 802.3 within As part of the restructuring and updating structured building cabling. of ISO/IEC 11801 standards series (as 3rd Single-pair transmission channels What do the standards activities look like for single-pair Ethernet communication? First of all, standardisation is a continuous, dynamic process, which develops and publishes new standards, revokes existing papers or updates and launches new standards projects. Therefore, this white paper is just intended to be a snap shot of the state of standardisation standardisation.. Standards activities in IEEE802.3 de�ne the Ethernet transmission protocol and de�ne the minimal requirements for link segments (link segments are not identical but similar to the transmission channel of cabling). ISO/IEC JTC1 SC25 WG3 de�nes the required cabling and in doing so relies on the component standards for cables and connectors, which are given in the IEC standards groups. As already mentioned, the following IEEE 802.3 standards have already been published: IEEE 802.3bp 1000 BASE-T1 “Physical Layer Speci�cations and Management Parameters for 1 Gb/s Operation over a single Twisted Pair Copper Cable”. Cabling design standards on European and international level scheduled for 2018/19. In this, single-pair Ethernet transmission 11.2017
industrial ethernet book
G N I T R A H : E C R U O S
T e c h n o l o g y
G N I T R A H : E C R U O S
31
y y g g o l o l o o n n h h c c e e T T
edition) it will also be determined in which application-speci �c parts an addition with single-pair shielded balanced cabling is technically and economically feasible. Initial consideration seems to suggest this is so for ISO/IEC 11801-3 (industrial applications) and ISO/IEC 11801-6 (building automation). Publication is expected in 2018. At the same time, the cabling speci�cations allow the requirements for the components, cables and connectors to be derived. This is performed for cables in the IEC SC46C standards committee and for connectors in the IEC SC48B standards committee (SC = subcommittee).
Cables for 1 Gbs over one pair These international standards titles describe cables that are suitable for IP20 and IP67 T1 connector design studies for SPE. transferring 1 Gbit/s over a balanced pair. Application areas include of �ce, home according to 1000Base T1 over a single-pair cabling channel. and industry. The use of 4-pair data cables should also On the one hand, this protocol can be be possible, which are capable of operating 4 transferred using existing four-pair cabling single-pair transmission channels. This feature according to category 7 / transmission class is also known as so-called “cable sharing”. The F (speci�ed up to 600 MHz) or according to transmission parameters should be de �ned category 7A / transmission class FA (speci�ed for a frequency of up to 600 MHz. This up to 1000 MHz) according to the relevant international standard should be published by quali�cation and with consideration of the 2018/2019. length restriction of 40 m. This opens up the IEC 61076-3-125: “Connectors for electronic option of “cable sharing”, which allows several equipment - Product requirements - Detail single-pair Ethernet services to be transferred specification for 2-way, free and fixed using a four-pair cable. connectors for data transmission up to 600MHz On the other hand, and this is generally with current carrying capacity the case, new single-pair cable and connector Following the application areas and products are created to serve new single-pair performance of the single-pair cables, the cabling structures on the basis of single-pair two-pole connectors are being standardised Ethernet. Important points for the design of up to min. 600 MHz. Standardisation of the the cabling components include: connector means that the mated interface will • Impedance 100 Ω, bandwidth 600 MHz be fully de�ned. De�nition of the interface and the associated fixed parameters, ensures plug compatibility and guarantees such as insertion loss, return loss, alien that products from different manufacturers cross-talk etc. can be used. It is expected that various • Comple te s hieldi ng t o en sure designs of single-pair connectors will then be transmission quality under extreme EMC available in safety class IP20 to IP65/67. The conditions publication of this standard is also scheduled • Single-pair cable with the smallest for 2018/2019. possible outer diameter (space and weight savings) for �xed and � exible exible installation Balanced transmission channels The theoretical basis for designing a • Two-pole connectors in the smallest possible design form for use in IP20 40 m channel with single-pair cabling has and IP65/67 environments – mutually already been worked out. T his means that the interested manufacturers of electronics and compatible plug interfaces. cabling have all the necessary information on the development and design of chipsets, Conclusion and outlook cables and connectors at their disposal. The increasing network requirements driven by The �rst chipsets are already available on the demands of I4.0 and IoT rely on innovative the market. However, a range of new products, and application-speci�c solutions. Single-pair which offer optimal support for the individual Ethernet offers a solution for cable-based applications, are still expected. Accordingly, communications infrastructure. Particularly devices �tted with “single-pair Ethernet” are for application areas in industry and building expected within two to three years. There management, this represents a smart addition are basically two ways to transmit Ethernet to the communications landscape, which
32
combine Gigabit Ethernet performance, transmission reliability, optimal handling and remote powering as well as space and weight savings. The normative basics have already been de�ned in IEEE 802.3 Standards for applications within the automotive and non-automotive sectors. For the respective non-automotive applications, the planning orientation incorporated within the international standards of ISO/IEC and IEC is used. The respective standardisation projects have been started. The compact design of the device connectivity and the Ethernet compatibility according to IEEE802.3 offer device development, e.g. within automation as well as sensor and actuator production, a networking concept that represents a simple change from bus- to Ethernet technology. This allows Ethernet to penetrate further into the field level, reduces enormously times for parameterisation, initialisation and programming and expands the range of functions of devices. Single-pair cabling saves space, installation time and costs. At the same time new applications are tapped, which were previously reserved for cable-based infrastructure. After the internet and Ethernet have connected people, computers and machines both in terms of space and time, this is now also happening with objects and things. The backbone of this new technology is provided by, amongst others, single-pair balanced copper cabling. With this it becomes clear that the connection between single-pair Ethernet technology and is more prevalent within the mega trends of IoT and I4.0 than in cloud computing and big data. Single-pair Ethernet represents an important technological progression, but is still only an addition to existing Ethernet technologies that use multi-pair copper cables or fibre optics and will not replace them. G N I T R A H : E C R U O S
Final thoughts Single-pair Ethernet cabling opens up new application areas, such as in industry and represents a useful addition to existing four-pair cabling systems. Therefore, singlepair Ethernet particularly supports trends such as IoT and I4.0. In particular, singlepair Ethernet can provide an important technological basis to the further development of multi-pair cabling within the development of cloud computing. Matthias Fritsche, Product Manager Device at HARTING , Rainer Schmidt, Busine Business ss Develop Develop-ment Manager for HARTING and and Yvan Engels, Strategic Market Development / Standardization BU Datacom, LEONI Kerpen GmbH.
industrial ethernet book
11.2017
IIoT best practices practices:: guidelines for MQTT architectures
T e c h n o l o g y
MQTT has three distinct features that make it an ideal IIoT protocol: low bandwidth, TLS security and stateful awareness. Among protocols in the pub-sub category, MQTT provides a foundation for building new architectures as long as users follow best practices and effective technical guidelines for implementation. N O I T A M O T U A E V I T C U D N I : E C R U O S
MQTT decouples devices from applications and reduces bandwidth usage. Devices connect directly to a MOM, or the MQTT server, where data is gathered.
THE INDUSTRIAL AUTOMATION INDUSTRY is bene�ting from the incredible opportunities made possible by the Internet of Things (IoT). While the IoT has shown incredible promise within the corporate and consumer environment, the true value of the IoT can be found in the industrial space, and the Industrial Internet of Things (IIoT). The thirst for industrial data has ignited this IIoT movement to bring operational technology (OT) up to speed with its enterprise counterpart, information technology (IT). This movement aims to overcome hurdles that have handicapped the growth of the industrial world, and to connect data across a wide network throughout an organization. The IIoT unlocks data, clearing the way for easy access and shareability. By working with IT, OT can leverage the scalability and � exibility exibility of open technologies to access and share all types of data with every level of an organization. In this article, we’ll provide some best practices when approaching new IIoT infrastructure projects.
New IIoT infrastructures There is a lot of hype about the IIoT and many organizations want to leverage the bene�ts it promises. However, for many organizations, the path to technological adoption seems unclear, and some still question if IIoT will ever happen. Fortunately, with current and emerging 11.2017
offerings, organizations can actually take full advantage of IIoT today. Before making the leap, though, they should recognize that legacy devices are still in use. Planning and patience are required as your team moves forward with an IIoT solution for your organization. As the old saying goes, look before you leap.
Build a parallel infrastructure There are still hundreds of millions of proprietary legacy PLCs and devices being used by organizations today, and they will continue to be in use for many years to come. Upgrading all of these devices would be incredibly cost-prohibitive. It would also be very difficult to just switch to a new technology, because making a quick switch could result in a catastrophic failure and loss of revenue. The best approach is to build a parallel infrastructure alongside with your existing installation and gradually transition devices from your old system to a new IIoT infrastructure. Many systems are critical in nature and upgrades could cause outages, which are unacceptable. Building a system in parallel allows you and your organization to compare data from your established system with your new system. The gradual approach helps to make sure your new system works, and is stable before making a complete infrastructure transition.
industrial ethernet book
Allow time for testing Migrating to a brand-new IIoT system of a large magnitude requires thought and thorough planning. This is a process that shouldn’t be rushed or taken lightly. Taking your time affords the ability to test your system. As your company gradually builds new infrastructure, testing along the way makes sure that communication is stable. Furthermore, if a failure occurs while you install your new infrastructure, the current system is still available, mitigating any downtime. As your team begins developing a plan for your new IIoT infrastructure, you should start looking at which communication protocols to use in your infrastructure. The protocol chosen will determine the IIoT devices and software for your infrastructure. Take the time to understand the needs of your organization and how your current system is setup. The �nal solution you choose is a large commitment. Once implemented, your infrastructure will be in place for many years to come. In the next section, we’ll look at MQTT and why it is an ideal communications protocol for IIoT.
MQTT as IIoT messaging protocol The entire IIoT solution will heavily depend on the protocol selected, as it is the backbone of your system. Most common IIoT protocols fall into two
33
N O I T A M O T U A E V I T C U D N I : E C R U O S
y g o l o n h c e T
Cirrus Link MQTT modules leverage a rich feature set and SQL database capabilities to take existing equipment and systems into a robust IIoT infrastructure.
categories. One category is the publish-andsubscribe (pub-sub) protocols which connect and publish data to a topic on an intermediary broker. MQTT, AMQP, DDS, and XMPP are examples of pub-sub protocols. The other category is the poll-response or client-server protocols, such as AllenBradley, Omron, and Modbus, in which clients continually connect to the server and make requests to determine if any data has changed. Of the two categories, which one should your team choose? To effectively build a highly scalable solution with a high level of ef �ciency, it is best to adopt a publishsubscribe communication protocol. Rather than connecting applications directly to devices, publish-subscribe protocols decouple devices and allow applications to connect to middleware. Through middleware, the system can connect any application that requires data from any device without placing any heavy demands on the network. From the list of available protocols in the pub-sub category, we highly recommend using MQTT. More than just a protocol, MQTT is the foundation for building new architectures, making IIoT a reality today.
MQTT communications protocol While MQTT’s recent emergence into the limelight may suggest that it’s a brand new technology, MQTT has been around for quite some time. In 1999, Dr. Andy Stanford-Clark of IBM and Arlen Nipper invented a messaging protocol that was mainly intended for real-time, oil-and-gas SCADA systems. At the time, operational technology and information technology were two separate worlds. Unlike IT, bandwidth in OT was neither free nor unlimited. In an effort to circumvent the communication limitations of OT, MQTT was designed to be a lightweight, pub-sub protocol that economizes on bandwidth. However, the
34
true value of MQTT is now found in its ability to decouple edge devices from applications that need the data. Traditional poll-response communication protocols can eat a lot of bandwidth without providing any real value. MQTT’s pub-sub method allows devices to put data on message-oriented middleware (MOM). Instead of applications constantly checking devices for any value changes, applications can connect to a MOM and subscribe to the important data that they need, including device state information. Since MQTT has proven to be a formidable communications protocol, its use has gone far beyond the oil and gas industry, and it has emerged as the de facto standard for I IoT and M2M messaging. In the Eclipse Foundation’s 2016 IoT Developer Survey, 80 percent of the respondents chose MQTT as the leading protocol for IIoT. MQTT is becoming more available as manufacturers begin to embed MQTT onto their devices. With so much interest in MQTT, it is safe to say that MQTT is the best choice for your IIoT solution.
MQTT the ideal protocol? MQTT has three distinct features that also make it the ideal IIoT protocol: low bandwidth, TLS security, and stateful awareness. Limited bandwidth presents a serious challenge to IIoT, especially for remote locations, which is why MQTT is the perfect solution. It is a lightweight, low-bandwidth communications protocol that uses a pub-sub methodology. Poll-response protocols send and receive a lot of repetitive data which can take up an unnecessary amount of bandwidth. MQTT employs a MOM which decouples devices from applications and thus reduces bandwidth usage. Devices connect directly to a MOM, or in this case the MQTT server, where data is gathered. Applications then connect to the MQTT server, getting an update whenever there are changes to the data.
The second important feature is the use of a cryptographic security protocol called Transport Layer Security (TLS), which provides communications security over a computer network. TLS aims to provide privacy and data integrity between two communicating computer applications. It is designed to prevent eavesdropping and tampering. By using TLS, MQTT establishes a secure, private connection via a handshake process. Once a connection is made, data is encrypted and transmitted between the client and the server. If the handshake fails, data is not transmitted. In addition to providing low bandwidth and a high level of security, MQTT has a useful feature called stateful awareness. While current SCADA implementations purely transmit data from devices, MQTT also sends the device state data about the health of the device or network connection. This is important for remote locations because it enables operators to determine if network connections are operational or devices are unavailable. As we dive deeper into the best practices for IIoT, we will discover that stateful awareness is one of the key ingredients to a successful IIoT implementation. Next, let’s look into the importance of stateful awareness and how to implement MQTT.
Built-in stateful awareness With its low-bandwidth publish-subscribe methodology and TLS security, MQTT has proven to be a formidable IIoT communication protocol. Another feature that is critical to your IIoT infrastructure is the stateful awareness that is built into MQTT. Stateful awareness is important for SCADA systems, especially for remote installations. Knowing the health of the device and the network connection helps to mitigate any downtime and ensures data is being shared with all levels of an organization. By having stateful awareness, data becomes more stable,
industrial ethernet book
11.2017
reliable, and contextual. Most enterprises still depend on legacy pollresponse communication protocols to be able to know the state of the network connection between devices and the SCADA system. Unfortunately, devices must be polled frequently to determine whether or not a network connection is good, which can put a strain on the system.
Stateful awareness in MQTT MQTT has stateful awareness built in and it is the only stateful architecture available. It is designed with a “last will and testament”: if the device stops working and falls off the network, then the MQTT server will publish a “death certi�cate” and the device will be marked as being unable to publish data. On a larger scale, with thousands of devices connected to the MQTT server, it is important to know within seconds the state of each device: whether it is online and ready to publish data or if it is unavailable. Let’s say that you’re using the Ignition platform with an MQTT server and an MQTT client. When a device connects to an MQTT server, it registers its state and then it registers its last will and testament. Ignition and the MQTT client will know that the devices are online and will deliver information if and when it changes. In the event of hardware failure or environmental issue, the MQTT server will publish the fact that the device is no longer available. In Ignition, those tags are represented as stale data and the device is marked as unavailable. When the device comes back online, it republishes its birth certi�cate. The MQTT client knows that the device is available, and Ignition shows the updated tags and the device’s availability.
Awareness improves processes Stateful awareness is a subtle but powerful feature of MQTT. There are many MQTT implementations that are stateless, but for SCADA implementations, stateful awareness is essential. MQTT uses reporting by exception (RBE), which is made possible by stateful awareness. Data is only sent when there are changes to the state of the device or when data values change, which reduces the amount of useless data taking up bandwidth resources. Knowing the device state is valuable since it helps to provide context to the data. Operators, especially, can keep track of devices and quickly pinpoint any trouble spots without having to send a technician out to a location to verify an issue. On the organizational level, data can be veri�ed to be up-to-date and accurate.
Ways to implement MQTT Now that we have established that MQTT is the ideal communications protocol for your IIoT 11.2017
system, our next step is to look at ways to start implementing MQTT. There are three main strategies to transition your SCADA system over to MQTT: converting existing devices to MQTT, enabling existing devices to communicate with MQTT platforms, and embedding MQTT directly onto devices. The �rst strategy is to convert legacy devices to use MQTT. An edge-of-network device is designed to communicate with legacy devices using their native protocol. The edge gateway then connects directly to an MQTT server. The poll-response is moved to the local level, and data is converted to MQTT and published to an MQTT server. This strategy is ideal for current installations using legacy equipment and traditional poll-response protocols. The second strategy is to enable edge devices to communicate with MQTT platforms using the Sparkplug speci�cation from Cirrus Link Solutions. Cirrus Link provides opensource software, tools, and the Sparkplug reference speci �cation to allow applications, sensors, devices, or gateways to seamlessly integrate with Ignition using the Cirrus Link MQTT modules. The third strategy, which is appropriate for newer installations, is to use devices with MQTT already embedded into them. Manufacturers have begun to offer devices that have the Sparkplug speci�cation enabled, making them ready to install and connect to your MQTT server and to the rest of your IIoT implementation. In this strategy, these edgeof-network devices do not require a separate edge gateway since the MQTT functionality is already built in. Now that we have established the importance of stateful awareness and how to implement MQTT, we can turn our attention to edge-of-network devices, which act as a bridge between PLCs and the MQTT server or “broker.” This capability makes them a critical component in the MQTT architecture and IIoT infrastructure.
Redundant edge gateways Regardless of whether a location is local or remote, connectivity can pose a major challenge. Local locations tend to rely on hardline connections to transmit data. Remote locations rely on wireless services such as cellular or satellite. In either case, the main communications conduit could potentially fail. As a best practice, especially for missioncritical systems, make sure to integrate failsafes and install redundant edge gateways.
Edge devices and gateways Edge gateways are a type of edge-of-network device. Edge-of-network devices are a key component in MQTT architectures, providing an entry point into an enterprise core network. Edge devices can include routers, routing switches, integrated access devices (IADs),
industrial ethernet book
multiplexers, and a variety of metropolitanarea network (MAN) and wide-area network (WAN) devices. An edge gateway can be thought of as a combination of a router, network box, terminal server, and a net- work arbitrator. As their name suggests, edge gateways live at the outermost edge of a SCADA system. With an abundance of legacy PLCs and devices still using poll-response communication protocols, edge gateways act as a bridge to connect to these legacy devices, converting them to MQTT, enabling them to communicate to MQTT servers, and allowing enterprise networks to access the data.
T e c h n o l o g y
Redundant edge gateways Putting in failsafes is a must for the SCADA transition. The data you’re collecting and sharing is important and any failures can lead to negative effects on your organization. Because edge gateways are critical, adding a redundant edge gateway is a best practice. It is also highly recommended that you add redundancy to your IIoT infrastructure as a whole. Make sure there isn’t a single point of failure that can cripple your operation. You should add redundancy at every point in the system where data is published. Make sure you have edge gateways that are able to communicate via cellular and satellite. Set up multiple MQTT servers and use all available channels to make sure data is available at all times.
Always have backup systems Redundancy is crucial for your IIoT implementation, especially when you have installations in remote geographical areas. Having a failsafe ensures your data is safe and available when it is needed the most. If there are system failures, having backup systems ensures smooth operation and minimizes downtime, which could save your organization thousands or millions of dollars. The key to a redundant architecture is to take advantage of multiple communication channels. Having a hardline system is always preferable, but having a wireless backup such as cellular or satellite ensures your system has continual coverage to ensure your valuable data is safe and your system keeps running smoothly. Next, we’ll discuss options for the edge devices, MQTT servers, and MQTT clients in your MQTT architecture.
Use MQTT modules for IIoT apps MQTT is an incredible communications protocol that is ideal for your IIoT infrastructure. Yet, you still need an industrial platform that fully takes advantage of MQTT and brings IIoT together. With Cirrus Link’s MQTT modules, Ignition becomes the ideal IIoT platform. The Cirrus Link MQTT modules leverage Ignition’s rich feature set and superb SQL database
35
y g o l o n h c e T
capabilities to take existing equipment and systems to create a robust IIoT infrastructure. Depending on speci�c needs, be it an edge gateway, an MQTT server, or enabling MQTT functionality, the Cirrus Link MQTT modules will create a solid solution. Ignition I gnition architectures with MQTT are comprised of several elements: edge devices, MQTT servers, and MQTT clients. Each of these elements plays an important role in your ability to take a legacy system and migrate into a cutting-edge SCADA system.
small, self-contained MQTT server. It provides you with a complete MOM solution that is best suited for an on-premise MQTT infrastructure with a limited number of edge-of-network devices. The module provides rapid development and is ideal for situations where communications are restricted or costly. It’s designed to simplify and speed up the process of getting a complete MQTT infrastructure going. It’s also very effective at increasing data throughput for high-performance plant- � oor oor solutions.
Edge-of-network devices The edge-of-network device is the first important component of the MQTT architecture. Edge devices which include edge gateways (also known as directors) allow you to communicate to legacy devices such as PLCs and RTUs, to collect tag and state data, convert it to MQTT, and publish that data onto an MQTT server. Edge gateways, along with MQTT, allow you to decouple devices from applications, thus improving bandwidth usage. There are four methods for implementing an edge-of-network device. The �rst method is to use a dedicated edge gateway to bridge legacy devices to new devices or to an MQTT server. The second method is to install a brand-new edge device that natively communicates via MQTT. Several manufacturers are now embedding the Sparkplug specification onto their devices, allowing for direct communication with an MQTT server. The third method is to use the Cirrus Link MQTT Transmission Module on an Ignition server. The module turns the server into an edge gateway, allowing you to collect and publish edge data to the MQTT server. The fourth method is to use Edge MQTT, a limited, lightweight solution that turns touch panels, client terminals, or virtually any embedded PC or �eld device into an MQTT-enabled edge gateway.
MQTT servers The second piece of the architecture is the MQTT server, often called the broker. This is where the message-oriented middleware (MOM) resides. All edge-of-network devices in the MQTT architecture publish MQTT tag and state data to the MQTT server. The MQTT server then enables MQTT clients to securely connect and subscribe to the device’s published data. Since MQTT is an open standard, there are many companies making their own brand of MQTT servers. For example, there’s AWS IoT from Amazon, Azure IoT Hub from Microsoft, and Chariot from Cirrus Link, as well as HiveMQ, CloudMQTT, Red Hat AMQ, and VerneMQ. There are many options to choose from, whether it be a locally hosted or cloudhosted solution. As a best practice, use the Cirrus Link MQTT Distributor Module. The MQTT Distributor Module is launched by the gateway and is a
36
MQTT clients The third piece of the MQTT architecture is the MQTT client, which connects to the MQTT server and subscribes to one or more topics of information, bringing that data right into an application. While there are many MQTT client tools available, it is recommended to use the Cirrus Link MQTT Engine Module for Ignition. The MQTT Engine Module is the key component that enables Ignition to act as a native MQTT citizen. The MQTT Engine allows the platform to communicate bidirectionally with MQTTenabled edge-of-network devices via the MQTT server, which can be sent securely all the way down to the device. It takes data from the MQTT server and injects it into industrial SCADA applications. Now that we have covered all the available options, resources, and best practices, it is time to look at how to bring everything together. In the last section, we’ll take a look at the best migration strategy to take when implementing an IIoT infrastructure.
Optimal IIoT migration strategies Migrating to a new IIoT infrastructure takes time and careful planning. As we discussed in the �rst best practice, you must approach the migration transition slowly. There are many pieces involved with an IIoT infrastructure and when you factor in the added complexity of a legacy system, you need a slow transition to ensure that downtime is minimized. Many organizations face a Catch-22 when implementing a SCADA infrastructure upgrade. Current SCADA solutions still use the poll-response protocol drivers that are directly connected to field devices over a communications channel or a TCP/ IP network. Because of this, they cannot replace or upgrade the poll-response protocol on the SCADA host until the new protocol is in the �eld and, vice versa, they cannot upgrade devices until they have a new protocol on the SCADA host.
Best way to migrate systems There is a proven four-step migration strategy that uses the Ignition platform, the MQTT Engine Module and an edge gateway. The four steps are installing an edge gateway, starting the poll-response, enabling
MQTT local masters, and switching over to the pure MQTT solution. Step 1: Install and set up an edge gateway, such as an Elecsys Director. The edge gateway acts as a TCP/IP cellular, VSAT, or Ethernet IP endpoint. In this step, you are setting up the edge gateway to communicate with PLCs or edge devices using the poll-respon poll-response se protocol. The edge gateway then connects to an MQTT server using a TCP/IP link and sends collected data via the MQTT protocol. Step 2: Start the conventional poll-response by connecting to the internal terminal server and keeping poll-response going. You will enable both the serial and Ethernet connections between Ignition and the �eld devices using the edge gateway. Step 3: Enable MQTT local masters. Once the conventional poll-response protocols have been enabled, legacy SCADA users can start to see the conventional use of Ignition. The resulting parallel communication system can compare values coming in from the conventional poll-response and publishsubscribe of MQTT. Step 4: The system is now ready to switch over to a pure MQTT solution. Once the organization is happy with the �nal, pure MQTT infrastructure, you can remove the OPC poll-response components. This will greatly simplify the network topology and creates a clean and pure MQTT solution. Furthermore, since the solution provides a plug-and-play SCADA system, it is easily scalable and can quickly grow with your organization’s needs.
Best practices recap To recap the best practices for a successful IIoT implementation, we recommend: • Planning the strategy and adding to your infrastructure in pieces, giving opportunities for testing and making sure everything is working. • Choosing MQTT as your IIoT messaging protocol since its feature set is ideal for an IIoT infrastructure. • Leveraging stateful awareness to help maintain the health of your IIoT infrastructure. • Employing a redundant strategy throughout your solution. • Using advanced advanced technology in the MQTT engine, transmission and distributor modules to simplify integration. • Finally, following following the optimal optimal migration strategy to ensure a smooth transition to a new IIoT infrastructure. The best practices discussed in this article are proven methods for success. Even with a legacy system, the solutions offered reduce friction and offer the resources needed to move an existing installation into a state-ofthe-art IIoT and SCADA solution. Technology report by Inductive Automation Automation.
industrial ethernet book
11.2017
Reader Service Card IEB issue 103 - November 2017
IMPORTANT: You must update your subscription annually to continue receiving your free copy of Industrial Ethernet Book magazine. Return by mail to:
Or use our online reader service at:
IEB Media
www.iebmedia.com/service
Bahnhofstr. 12 86938 Schondorf Germany Please enter your contact details below:
Company Activity (select one) □
Name: Position: Company:
___________________________________ ___________________________________ ___________________________________
□
Address: City: State:
___________________________________ ___________________________________ ___________________________________ ___________________________________
□
Zip Code: Country: Phone: Email:
___________________________________ __________________________________ _ ___________________________________ ___________________________________ ___________________________________
□
□ □
□ □ □
□ □ □ □
I want to:
□
□
Start a new subscription
□
Update my subscription □
Digital edition or
□
□
Print edition
Aerospace/Defence Electronics Industrial/Consumer Instrumentation/Measurement/Control Manufacturing Automation Metal Processing Mining/Construction Oil & Gas/Chemical Industry Packaging/Textiles/Plastics Pharmaceutical/Medical/Food & Drink Power Generation/Water/Utilities Research/Scienti �c/Education System Integration/Design/Engineering Telecomms/Datacomms Transport/Automotive Other: ________________ __________________________________ _____________________ ___
Job Activity (select one)
□
Change my address
□
Engineer - Instrumentation & Control
□
I do not want to receive promotional emails from
□ □
□
Industrial Ethernet Book I want to be removed from the subscription list
Engineer - Works/Plant/Process/Test Engineer - Research/Development Designer - Systems/Hardware/Software Manager - Technical
□ □ □
Signature: Signatur e: __________________ _____________________________________ ___________________
□ □
Date: ________________ __________________________________ _________________________ _______
□
Manager - Commercial or Financial Manager - Plant & Process/Quality Scienti�c/Education/Market research Other: ________________ __________________________________ _____________________ ___
IEB Media reserves the right to refuse an application for a free copy of Industrial Ethernet Book or the provision of information on any of the advertisers or articles
S e r v i c e
y g o l o n h c e T
Industrial web-based computing: is data intelligenc intelligence e �nally here? Fog computing and cloud computing are no longer strictly processing partitioned, which leaves more power in the control centre at quite minimal costs. Another key advantage is that no longer are very powerful computers needed, nor is there a need for high levels of human intervention or even monitoring. DATA INCLUDING TEXT, PICTURES, RAW BITS and bytes that tell humans things has been around for a long time, from the early grunts and cave drawings, to the printed word. Making sense of it all and to put data to use, on the other hand, takes understanding and processing. Processing needs a brain or a computer to give us information. Why? The amount of data can be huge and to bring it down to a manageable size may lose points of interest, so encapsulating that data in a wider sense with understanding of where the data is from and what it is about helps enormously in forging solutions. The UK Meteorological Office takes 10 million observations on the weather every day but if you watch a weather forecast the information presented rarely takes more than 5 minutes. How is this done; by targeting the audience and encapsulating the raw data in information packets, packets which have been processed, analysed and organised in order to provide succinct details. An interpretation of this is much like one word being able to insinuate many ideas; the term “congested road” gives the picture of a traf �c jam or could simply be a road containing many cars dif �cult to pass, would this also lead to frustration and anger? If we add just one further idea of “congested urban road” then just that one extra piece of data puts the visualisation into context and makes clear the thought on the subject. This leads to the preposition that digital data can provide intelligence. In software the idea of concatenating bits into binary arrays where a 16 bit word contains digital � ags ags indicating many things, can be carried further by de�ning an object structure of say “Door Operation”, a door being opened or closed and a time for how long the door has been opened or closed. Add to the structure who opened the door and then an extrapolation may be made as to why the door was opened. Such situations are seen as data providing intelligence rather than being intelligent in its own right. What if we pass to a centralised core not real time data but extrapolated data on the subject? First, let us provide some definitions on which we can more easily describe the segmented parts of the subject under discussion.
38
A X O M : E C R U O S
Using a ring topology can automatically correct standard errors and faults in the transport layers.
The cloud
Fog computing
An ethereal place of residence on networks circling the globe, and today, of near orbit, where servers and storage can be found and used for data derived in a more physical world. wo rld. Provided and patrolled by an invisible though powerful entity, the community at large, it is very much inde�nable though effectively easily usable.
As the name implies, this is processing done on the data but the computing engine is close to the edge or at the point of data collection. Unlike cloud computing this is very much under the control of the application developer and it is usually left to the developer to not only implement it in the system but also to ensure ancillary services such as connectivity and backups are maintained as well.
Cloud Computing By having the processing carried out in the cloud by multi-user and powerful computers it alleviates the cost of having a powerful computer in the local environment; optimising machine cost and, to some extent, development costs due to the application frameworks or Applications as a Service, more commonly today referred to as Software as a Service (SaaS), provided by cloud computers. Such points as regular backups and validated recovery mechanisms are bene �ts to this method of computing but there are ongoing regular costs to take into account also for such things as bandwidth usage and amount of data storage.
Grammar
Fog
Shrink boundary & extend the area
In the Operational Technology (OT) world the fog is so termed as it is, like the climatic condition, is close to the ground or, more precisely, close the real world interface layer at the edge of the industrial topology used to create effective plant networks.
It would seem incongruous to attempt to take a circle and shrink the circumference but increase the area covered by the circle. Here we now move between the physical world and the metaphysical, or possibly more understandably, the modelled world.
Akin to language we now look at how data can be visualised more succinctly. The very de�nition of grammar is placing meaningful words in a correct contextual sense whereby accepted words of the language are used within an accepted boundary, the context. This also provides the implicit facility to have the same word having several different meanings and raises the question as to how we can utilise similar techniques with the processed data both to aid understanding but also ease the necessary processing to achieve optimum usage and ef �cient deployment in the network environment.
industrial ethernet book
11.2017
A X O M : E C R U O S
T e c h n o l o g y
The reaction of the fog is far faster than that of the cloud, so even with a catastrophic failure the motor can be stopped in highly distributed control systems.
To take as an example a CNC machine which has detectors applied monitoring such data points as the size of the material to be worked on, the speed of the cutters, the temperature of the cutters, the temperature of the material being worked, the position of the cutting head, the power used in moving the head. Those data points are our circle of the world the CNC operates within but what else can we achieve from these? Obviously this close to the edge the processing needed is required to act in real time but only small applications are needed with the objectivity detailed in small chunks of processing. This can be achieved with small RISC computers such as Moxa’s IA260 or even the UC-8100 series which, in addition, have the ability to communicate wirelessly as required. The fog computers themselves can receive the real world data in standardised format such as Digital IO or serial packets but having networking connectivity can also receive digital format data such as in Modbus/ �eldbus format from serial to Ethernet converters as well as Iologik IO modules, each of which themselves also have variants for native wired Ethernet or wireless capabilities. Can we optimise anything here to lower the total cost of manufacture? Take the cutter temperature, if we statistically analyse the pro�le of the material being worked and the temperature of the cutting tool we can then make an assumption as to the temperature of the material. From there we can control the speed of the machine, the cut depth, as well as the optimum wear of the cutting tool for the process being performed and ensure the material tempering is not affected by the cutting process itself. With this method we can then, as you see, achieve a level of condition based monitoring of the tool as well as the material. In this example we have overcome the 11.2017
seemingly impossible paradox of both removing the need for more sensors (shrinking the boundary) as well as monitoring the whole process more fully (extending the area). In order to do this we need some processing power to apply the necessary algorithms but the question of the moment is, does this apply intelligence to the data as the data points are transformed from explicit data to implicit information?
Clarify the picture Taking a system as a whole entity we then come to the question of how to de�ne the details of the needed processing and ef �ciently make use of the system parts. For the most simple of system the partitioning is straightforward to utilise the whole attributes’ abilities to the full or even not to take any heed of them. However, for the more complex systems we must understand in full how each system attribute could be utilised most ef �ciently. So
what are these attributes? A typical list could include the following. At the fog or edge, the real world monitoring and control data that will be passing through the transport. For this, the cyclic parameter must be determined; the cycle time obviously must be suf �cient for system accuracy but also automatic failure detection and aspects needed to overcome such failures. Any processing that is to be applied in the fog has to be suf �cient to achieve the above desired results. File storage and retrieval times, computer bus speeds and ability to be placed automatically in burst modes, processor speed alongside number of pipelines and manipulation of apparent parallelism by kernels. Latency and jitter imported to system ef �ciency by all transport parts brought about by the transport protocols in use. Towards the cloud, the sufficiency of buffering and local storage that can overcome A X O M : E C R U O S
All layer layerss of the comm communic unicatio ation n and and machin machinee contro controll netwo network rk can can use use the the same same basic basic net network work tech technolo nologies gies..
industrial ethernet book
39
A X O M : E C R U O S
s y n g o i o t l a o c n i l h p c p e A T
Effective monitoring systems on wide area networks (WAN) can be created by integrating a combination of
connectivity outages for small time intervals. At the cloud, the level of information that is to be utilised to achieve the desired needs of the �rst point. We can now see that there is the possibility to have a distributed management process overseeing the system as we would want much of the data transform to be carried out in the fog. Information rather than raw data is passed up towards the cloud, lessening the required throughput and leaving less to be completed in the cloud which, although having possibly powerful computers may be used by many in a virtual machine environment (to minimise costs) and are more than likely not under our tight control. Let us take another example, in this case one most have encountered in some degree over time, that of aircraft operations. Today this is a good example of distributed control and monitoring as many countries have, or are migrating their airspace management to, a centralised system. Taking two aspects that are important, we have weather and aircraft position. Aircraft only make pro�t when they are airborne. As an aside, we often think of the hierarchical view of Command and Control as the real world being at the bottom and the overview being at the top. In this case, it is the aircraft that are physically above the control centre so in essence the physical and metaphysical have been reversed. Weather is reviewed on a long cyclic view,
40
� eld eld
devices, wireless data logging and monitoring software.
as the weather at height is important, not that at ground level, so satellite data is taken in as well weather monitoring stations. It is the aircraft themselves that could monitor their own weather (by radar and pressure sensors) and pass this as a more local and accurate view to the control centres. The centres can then have not only weather information as a 2D object but also as a 3D model. Ground-based radars throughout the country are monitoring the airspace and their data can now be joined to provide 3D positional informational which can be used to check the position being fed from other sensors both on the aircraft itself as well as other external aids. By distributing the monitoring between aircraft themselves, air �elds and localised positions, the information provided to central air traf �c controllers can be seen to be very accurate and ‘clean’. Notice again, as in previous examples that the fog is providing information forward and not just raw data. Information, a joining and contextualisation of several data points, is being used in preference to raw data.
But what can go wrong? The mechanism of providing information has one big disadvantage. The closer to an overview picture we move the information, the more diluted the data gets. Here we are looking at the distinction already described between data and information.
Failure in a good way Driving a motor at the correct speed continuously needs accuracy as, in the real world, many controllable and uncontrollable factors can affect the speed; not least of which are power surges, ambient temperature/ moisture changes, friction build up etc. However, monitoring the speed over time can give us an indication of the serviceability status of the motor in that answering the question of the current wear level will show when the motor may fail. We have already discussed that at the edge, or in the fog layer, the processing needs are for accurate, fast computers and introduced RISC computers but Moxa also has Intel Processor based computers which come in several form factors and capable to operate, in some variants in hazardous environments. The V2000A series being targeted at rail transport and DA Series speci�cally made for the energy generation markets. Alongside these are Panel PC models as well as straight processing platforms in the marine market. Such points then can be used to aid de�ning the function partitioning; whether to use the fog to process the data or the cloud. The time needed to get information to the cloud and make the decision as to whether the speed is correct may generally be satisfactory but is it ef �cient enough to actually introduce speed control? The fog would be more ef �cient to apply the speed control aspect with the
industrial ethernet book
11.2017
A X O M : E C R U O S
A p p l i c a t i o n s
Microsoft Azure IoT and OPC UA can work together to provide effective links between the private and public cloud.
cloud monitoring the serviceability state. There is also a further aspect to this. That of maintaining control even if errors or failures are affecting the system. The reaction of the fog is far faster than that of the cloud so even with a catastrophic failure the motor can be stopped, possibly reducing secondary damage and hence ef �ciently allowing maintenance to be more cost effective. On the other hand, maintenance can also be made more cost effective if the cloud monitoring the motor’s information can calculate when it is expected to fail and so schedule maintenance at the most appropriate time. When designing the system, we can also implement mechanisms as ring topology and use standard protocols to automatically correct standard errors and faults in the transport layers. De�ned and standardized to make the system rugged, such methods also can allow different devices to interoperate and ensure the rugged platform, and as such, data and information integrity, is maintained.
Failure in a bad way Always good engineering practice, the designer will obviously cater for most, if not every, failure condition that could be met within the system. Devices can fail, wiring can fail but such events can be b e catered for within devices and their reporting facilities but today the thing that should be to the forefront of everybody’s mind is cyber-security. A forced, intentional failure could be approached and caused anywhere in the system if it is open to abuse, the designer should cater for such in the design. The level of security applied is of course going to increase the TCO but when offset against such a potentially harmful failure, which could go undetected for some considerable time, it is more optimum to implement safety and security features than not. 11.2017
The story begins Everyone has recently started discussing cloud and fog computing but in reality they have always, relatively, been there. It is only now that the terms have been given meaning in the system function partitioning that clarity to the uninitiated comes and helps to target the system architecture design decision thought processes. System design can be seen to be based around a simple derivation; the data that is obtained from the real world, the information the data forms and the use the information is put to. Detailing the transform to information at the edge is where the fog lies. The transform actually clears the fog from the system, easing sight of the overall picture or control needed, allowing optimum use of resources such as lessening the bandwidth needs of information moving towards the cloud as well as aiding the edge peer to peer use of the information derived. Obviously, from such operations we have now formed several aspects of the system layer de�nition with time and effort to do so making time to market less. Take for example a water tank fed by streams used to irrigate farmland. It is desired to keep the water tank at a speci�c level to ensure good pressure to the irrigation system. Function partitioning is by functions looking at items which can be controlled in the fog and items which cannot be controlled locally too well are pushed to the cloud. Water purity and temperature are fed to the cloud but tank level is monitored and controlled in the fog. It would be pointless having an on/off control for letting the water into the irrigation, far better to have a variable opening which �ux x maintains the pressure but controls the ef � u amount over time as the amount of in � ux ux changes with the level of water in the streams. stre ams. In such a system the amount of data passed to the cloud is far less than having all the
industrial ethernet book
� ux pressure/level/ef � ux data passed upwards. cloud processing and storage is far less and so are cloud running costs.
Can data be intelligent? We started this journey asking if data can be intelligent. In most ways the answer has to be no, as to exhibit intelligence processing has to be involved. Intelligence in all guises understood today would seem to point at the need for an understanding of the end to end needs but Arti�cial Intelligence is based on many conjoined disciplines, not least of which is that of system operation utilising operations that behave akin to a neuron. A data point becomes the data itself, some self-imposed limits, feedback of the amortised data point and its output. Effectively now we appear to be on the cusp of data becoming intelligent in its own right with little processing. Add to this a data point becoming an information point, where information is passed through a similar ‘neuron’, as discussed the raw data is diluted but the information now aids a better overview and gives wiser system usage and control. One of the better points of all this metaphysical understanding is that, with the power of quite small devices today it is no longer the case that the fog computing and cloud computing are strictly processing partitioned. More, it leaves the control centre with a newly acquired power at quite minimal costs. No longer are very powerful computers needed nor is there a need for high levels of human intervention or even monitoring. Look at the vehicle industry today. Cars order their own spare parts to be replaced at the next managed servicing period as well as driving themselves. Intelligent data? Yes. Possibly in a premature state today, but it is de�nitely present. Moxa.. Alan Harris, Field Application Engineer, Moxa
41
y g o l o n h c e T
Fast roaming: a challenge for industrial Wi-Fi applications Fast roaming WiFi offers reliable and secure communication, especially for mobile applications. For train-toground applications and automated guided vehicles, wireless IEEE 802.11 networks are suitable because of long range and high data rates, and when participants can be moving over long distances at high speeds. N E D L E B : E C R U O S
Applicati Appl ication on exampl example e of traintrain-to-tr to-tracksid ackside e communi communicatio cation. n.
IEEE 802.11 WI-FI WIRELESS NETWORKS are used today in a wide variety of applications. This technology is well known for its long range and high transmission speeds. However, fast roaming is a particular challenge for the quality characteristics of Wi-Fi networks in industrial environments. Fast roaming is especially important when the reliability and security of communication in a mobile application scenario needs to be unaffected. However, due to the complexity of this application, optimizing a wireless network for operation is far from straightforward and offers technical challenges. Wireless networks can offer many new options for the implementation of industrial applications. On the one hand, they offer an easy-to-install option to provide facilities in changing environments with network communications. On the other hand, the use of wireless
42
networks minimizes the cost of applications in which wear and tear would damage or destroy cable connections quickly. In addition, the use of wireless communication systems becomes mandatory whenever communication between mobile clients needs to be implemented. Thanks to their long range and high data rates, wireless IEEE 802.11 networks are suitable for the sophisticated application scenarios of Train-to-Ground Communication and Automated Guided Vehicles (AGVs) in which the participants can be moving over long distances at high speeds.
Factoring Wi-Fi network quality The objective of train-to-ground communication is to establish fast and reliable signal transmission between trains and the subway and track-side infrastructure. The network on a train can connect WLAN clients on the train via specialized Wi-Fi with
different access points along the route. The communication range of the trackside access points and the wireless network on-train clients are particularly important for the reliability and ef �ciency of such a system since every switchover (roaming) of a client between two different access points along the route causes an interruption of the train-toground connection. Hence, frequent roaming degrades the connection quality, especially when the interruption is long. The network requirements for the AGV application are very similar in terms of coverage and interruptions. In this case, vehicles are moving autonomously through a manufacturing site to independently ful �l various tasks. The vehicles communicate with the infrastructure about sensitive and timecritical information necessary for autonomous operation, such as receiving control
industrial ethernet book
11.2017
commands. Thus any longer interruption on the communication network might cause the stop of an AGV which could lead to disruptions in the manufacturing process. The most important quality indicators of how a wireless network can meet the requirements of both applications are: • Packet loss rate: the percentage of sent messages (or packets/frames) that are not successfully received by the intended recipient • Latency : the delay in transmission for the delivery of a message via a wireless connection • Data throughput of the wireless connection: the ability to transmit a certain amount of data within a speci �ed time Interruption on: a break in transmission that • Interrupti takes place when a client roams from one access point to another • Communication range: the area covered by an access point or the seamlessness in the coverage of a facility that determines whether the Wi-Fi connections are strong enough to reach all necessary locations Generally speaking, the importance of each parameter varies according to the application. When it comes to train-toground communication and AGVs, reliable communication has top priority. The wireless network must deliver a certain data throughput with minimal packet loss at every point of the area. A standard requirement of a train-to-ground installation is 20 to 80 Mbit/s data throughput with less than 1% packet loss. Especially the requirement on high reliability is similar for AGV scenarios, since any interruption in communication might cause the AGV to stop its operation.
Quality of wireless networks To ensure this reliability can be achieved, the installation must have suf �cient network coverage; in addition, the interruptions of a mobile client during the switch from one access point to another should be as short as possible (typically < 50 ms). Insuf �cient coverage results in a stark reduction of the data throughput, and frequent interruptions that are too long lead to extreme packet loss. For these reasons, an optimal mechanism for changing the connection from the client to the access points factors into these both aspects. Roaming needs to occur as quickly as possible and must be initiated precisely when the client leaves the range of the current access point and the next access point offers a stronger signal transmission which leads to a more reliable data throughput.
State-of-the-art technologies Presently, there are various technological wireless network capabilities to enable client 11.2017
N E D L E B : E C R U O S
T e c h n o l o g y
A mobile mobile client client on a train or AGV AGV moves moves throug through h the the wireless wireless netw networks orks of of differ different ent access access poin points. ts.
devices to rapidly change between access points. Since the security of the wireless network should be ensured at all times, including in scenarios with high mobility, there should be no compromises of the implemented security technology in favor of faster roaming times. Therefore, technologies for faster roaming should always be viewed in the context of the underlying security mechanisms. These roaming enhancements are often speci �c to special hardware or software features and therefore are only available on certain wireless network products. For example, the current BAT devices of the Hirschmann access point series support the following technologies:
Fast roaming Although a mobile client moves through the transmission range of several different access points, the reliability of the communication and the available bandwidth must be guaranteed at all times. Ideally, to optimize bandwidth, neighboring access points with overlapping radio coverage should operate on different channels to minimize interference. A mobile client can connect automatically to the access point with the best signal. Fast roaming between wireless network access points has been possible for a long time. Interruptions of less than 50 ms can be achieved; however, even faster roaming requires further technical tricks and achieving such fast roaming times with proper security is even more challenging.
Reducing scan times When roaming between two access points, an on-train client must first identify the next target access point. This is not as simple as it may sound, because in order to avoid interference between adjacent access points, these access points typically operate on different channels, meaning different frequencies. However, a client can only communicate with access points on one channel at a time. Therefore, when searching for candidate target access points, the client must deactivate its current communication connection in order to search other channels/
industrial ethernet book
frequencies for suitable access points. A mobile client must therefore periodically interrupt its established connection to scan all eligible channels/frequencies to obtain an overview of signal strengths of the other access points in its environment. Only with this information can a client decide whether there is a possible connection with a better quality than the present quality, and then initiate the roaming process. Depending on the train’s speed and the associated changes in the environment of the WLAN client, the scanning processes must be performed repeatedly. Since the active connection cannot be used during these scans, it is not possible for the client to transfer the packets for the application during the scan – the network is not available whenever the client scans. For this reason, scan processes should be as short as possible.
Secure fast roaming Whenever a client decides to switch its connection to a different access point, it will initiate the procedure for the fast BSS (Basic Service Set) transition de�ned in the IEEE 802.11 standard, meaning the actual roaming to the better access point. In consideration of the highest WiFi security, fast roaming is usually labelled as Fast BSS T ransition. The security of a WiFi connection can only be guaranteed if a client properly authenticates at the target access point when connecting and if a valid key for this connection is provided for encryption of the data packets. This takes time and must be repeated with every roaming process, unless special techniques are used. Fast roaming is therefore only possible using a faster authentication mechanism. Over time, more and more (necessary and important) security mechanisms have been added to wireless networks, so that wireless networks today are very secure. But this security comes at a price: the connection setup and connection switching between access points is slower because the necessary security parameters must �rst be negotiated and exchanged. Here too, a certain level of technical trickery is needed to create both
43
N E D L E B : E C R U O S
y g o l o n h c e T
Applicati Appl ication on example example of automat automated ed guided guided vehi vehicle cle (AGV) (AGV) commu communicat nication. ion.
secure and fast Wi-Fi when roaming. In order to ensure both a fast and secure exchange, two problems must be addressed: • How can the mobile client switch as quickly as possible between access points? • How can the time for the the negotiation of security parameters be minimized? The following optimizations lead to a signi�cantly faster roaming while continuing to maintain good security.
PMK (pre-master key) caching The PMK Caching method also uses a full authentication via IEEE 802.1X. However, the client and access points store/cache the negotiated keys and can reuse them for quick access to their next connection. Nevertheless, this method for fast roaming can only be used to a limited extent, since a client would have to log in to all access points in the system for the roaming processes to use the stored key information for a fast connection later on.
Pre-authentication The Pre-Authentication method enables the client to authenticate via IEEE 802.1X to the next access point via the wired backhaul network, independent from the actual roaming procedure. This way, the client does not communicate directly with the access point via Wi-Fi but uses its currently active connection with the wired LAN in order to connect to the next access point. During this early authentication process, the Master Key is already negotiated between the client and the access point, which means that, when roaming at a later point, the connection to this access point is made without authentication. Although this method makes fast roaming
44
possible, there are still some disadvantages: as a requirement for Pre-Authentication, a c lient must be able to predict with which access point it will connect as early as possible. This information may not be available in certain circumstances, since a client would have to scan the Wi-Fi channels in its surroundings for access points often and continuously. This in turn leads to loss of performance and interruptions. Alternatively, of course, a client can authenticate itself with as many access points as possible, regardless of whether it will connect with them later on. However, since a full IEEE 802.1X process is required for every authentication, this approach generates a signi�cant load on the authentication server. Therefore, this Pre-Authentication method for fast roaming has limited applicability.
Opportunistic key caching The utilization of Opportunistic Key Caching (OKC) can provide fast roaming without generating a heavy load on the IEEE 802.1X authentication server. The central approach of this method is the managing of key information for all access points by a Wi-Fi controller. The Wi-Fi controller can distribute the authentication information to all Wi-Fi access points under its control. Therefore, a client must no longer negotiate its own Pre-Master Key for every access point but is able to use the same Pre-Master Key for all access points managed by the single Wi-Fi controller. The Pre-Master Key will be negotiated during the �rst IEEE 802.1X authentication. Thus, a client must only complete a single IEEE 802.1X authentication to any access point in order to connect to all access points of the network. For this reason, fast roaming times of 50 ms are possible through the use of OKC, despite the use of the full security of IEEE 802.1X.
IEEE 802.11r A conceptually very similar procedure to the Opportunistic Key Caching, 802.11r is speci�ed in the IEEE standard. A signi�cant difference between this specification and OKC is the use of a de�ned key hierarchy at the Wi-Fi controller and the connecting clients. Based on this hierarchy, the access point and the client are able to gain access to a part of the necessary information for key negotiation.
System solutions The software used for access points, clients and WiFi controllers offers solutions for both core challenges of fast roaming. On the one hand, comprehensive con�guration options for scanning behavior facilitate ef �cient, optimal roaming decisions. On the other hand, the mechanisms for fast roaming in combination with IEEE 802.1X authentication, such as Pre Authentication, Opportunistic Key Caching, and IEEE 802.11r are supported as well.
Reliability and security Both train-to-ground communication and AGV applications need reliable communication between fast moving participants and the stationary infrastructure. Based on the high mobility and the speci�c requirements for the data throughput with very low packet loss, optimal “fast roaming” with the highest WiFi network security is needed. Only with optimization of the roaming behavior, and with the very short interruptions associated with it, can the target of low packet loss for these mobile applications be achieved. Dr. Tobias Heer, Technology & Innovations and Dr. Bernhard Wiegel - Embedded Software Development, Hirschmann Automation and Control.
industrial ethernet book
11.2017
Wireless access points
Siemens: Additions have been made to the Siemens: company’s portfolio of network components with the new Scalance W1788 Access Points, designed to facilitate implementation of the current WLAN Standard IEEE 802.11ac Wave 2 in industrial applications. Users will bene �t from investment protection for industrial networks, future-proof wireless applications and projects in industrial environments. The standard will enable wireless applications with high bandwidths to be implemented at gigabit data rates, for instance, to transmit video data or where a high user density is involved. The integrated switch features two managed Ethernet gigabit ports offering wideranging networking possibilities such as link aggregation.The industrial feature (iFeature) iPRP (Industrial Parallel Redundancy Protocol) ensures reliable redundancy via WLAN even in tough ambient conditions. Scalance W1788 uses MU-MIMO (Multiuser Multiple Input Multiple Output) technology to structure data flows and achieve higher data transmission rates.
Wi-Fi gateway modem
Weidmuller: The WI-I/O-2-E-N-GBL wireless Weidmuller: networking I/O and Wi-Fi gateway accommodates multiple I/O nodes and extends communications to sensors and actuators in local, remote or dif �cult to reach locations. The gateway offers reliable and robust wireless technology with multiple bene �ts for industrial applications, including a simple web-based user interface, and a standards-based wireless protocol with a networking topology that is 11.2017
simple to use and con�gure. The new device can provide IP-based networking across sprawling industrial environments and includes built-in I/O capability for digital and analog inputs and outputs. The modem can be easily con �gured for use globally via a built-in webserver. The unit provides robust and secure two-way wireless communications for challenging indoor and outdoor industrial environments. An internal radio transceiver is designed to operate reliably even in applications with obstructed pathways, using Weidmuller’s ProMesh redundancy protocol. ProMesh networking provides mesh node remote units the ability to automatically detect available connectivity options and make decisions based on link quality. It also offers the ability to set �xed links, providing a high level of connection reliability and redundancy.
IIoT gateway starter kit
Moxa: To serve the needs of system integrators Moxa: To and engineers developing applications for the Industrial Internet of Things (IIoT), a new IIoT Gateway Starter Kit includes built-in support for Amazon Web Services (AWS). This dataacquisition-ready kit provides a ready-to-use platform that simplifies development of IIoT solutions by providing all the essentials needed to get data from edge devices to cloud services, with little to no programming required. This results in faster development, integration, and time to market, giving system integrators the boost they need. The main component of the starter kit is the ThingsPro Gateway, a ready-to-run dataacquisition software platform that simplifies the complex task of transferring edge data to the cloud. To simplify getting data, ThingsPro Gateway provides a Modbus framework to easily connect with Modbus RTU/TCP devices and SCADA systems. It also includes extensive network support for 4G connectivity, wireless failover, �rewalls, and VPN to ensure that data can be easily and securely retrieved from remote �eld sites. To get data into the cloud, it has built-in client support for services such as AWS IoT and Cirrus Link Sparkplug. By integrating the AWS IoT Device SDK, ThingsPro Gateway lets a user set up tags and devices on AWS IoT.
industrial ethernet book
Industrial ADSL/VDSL2 router
P r o d u c t N e w s
Westermo: An industrial ADSL and VDSL2 Westermo: router/modem provides robust and secure communications to remote industrial automation equipment. The BRD-355 uses the Internet to cost-effectively inter-connect systems, allowing SCADA, HMI, PLCs and sensors to communicate with each other. By providing remote access to equipment, the BRD-355 helps to remove boundaries, eliminates the need for time-consuming site visits and creates a suitable network infrastructure. The BRD-355 has been designed to support leased line replacement, analogue/dial-up modem replacement, operating broadband over ISDN and providing broadband for utilities. The BRD-355 provides a �xed broadband connection via ADSL or VDSL. Recent broadband protocol technology changes by telecommunication carriers has forced the industrial communications industry to adapt their solutions. The unit supports most ADSL/VDSL2 communication standards including ADSL Annex J and VDSL2 Vectoring. VDSL2 Vectoring enables data rates to be doubled, helping users to achieve up to 100Mbit/s over copper cables. This is particularly useful when �bre infrastructure is unavailable.
NC integrated controller
OMRON: The NC Integrated Controller provides OMRON: The G-Code functionality and numerical control functionality, enabling high-precision complex pro�ling and increasing the production capacity of processing machines. With changes and advancement of technologies, products with more diverse and complicated shapes and materials are now increasing while product lifecycles are becoming shorter. Along with these changes,
45
s w e N t c u d o r P
manufacturing sites are facing challenges of achieving more dif �cult processing at higher productivity rates. The NC Integrated controller provides both NC and PLC functionality and synchronizes NC processes and others at high speed. This will help signi �cantly increase the production capacity of the entire machine. NC setting and G-Code programming are added to the Sysmac Studio which provides a true Integrated Development Environment (IDE) for configuration, programming, monitoring, and 3D simulations. Function Blocks for NC make program structure simple, even for synchronization between NC process and others, cutting development time.
Unmanaged 8-port Gigabit switches
WAGO: Two new industrial unmanaged 8 port WAGO: Two gigabit switches have been added to its growing switch portfolio. Each of the RJ-45 ports support 10/100/1000Mbps speeds with autonegotiation and auto-MDI-/MDX detection. Housed in compact enclosures of 50 mm, these devices reduce the footprint of the control cabinet. They each have an operating voltage of 9 to 57 VDC and two LEDs per port for � exible exible and easy-to-use operations. The 852-1112 style industrial switch is DIN rail mounted and is powered with 24VDC.The 852-1102 industrial switch offers dual power feeds for redundant power capabilities as well as operations over a wide voltage range and a monitoring alarm relay. Differentiators between the two are as follows: The 852-1112 ECO switch provides the following feature set: single power supply connections and operating temperatures from -32°to 140°F. The 852-1102 standard switch offers: redundant power supply connections, and alarm relay, and operating temperature from -40°to 158°F. Both switches are offered at competitive prices, allowing for � exibility exibility in deciding which works best for a given application.
Industrial IoT edge gateway Robustel: Modular industrial IoT edge gateways Robustel: Modular support various communication protocols to facilitate fast application development.
46
conditions. The LNP-C500G series provides a 48~55VDC redundant power input with power polarity reverse and overload current protections. These switches also have high electrical fast transient (EFT), surge protection (2,000 VDC), and electrostatic discharge (ESD) (6,000 VDC) protection to prevent against any unregulated voltage. It can be mounted on Din-rail and wall mountable orientations.
Condition monitoring for mobile
The MEG5000 is � exible, exible, easy to con�gure and manage. It features three scalable cards that support a variety of interfaces to meet the changing demands of applications in the industrial Industrial Internet of Thing (IIoT). Thanks to quick deployment and simple customization the gateway can be tailored to virtually any industrial requirement. Through edge computing, the MEG5000 gateway is able to process data right at the network edge and in real time. It can therefore collect, analyze and act on data more ef �ciently, and it supports data optimization which is vital in the IIoT. When transferring large amounts of data to the cloud over limited bandwidth, latency might occur. MEG5000 supports up to 1300 Mbps Wi-Fi speed ensuring that its edge computing power helps to reduce data uploads by acting like a local, edge-based cloud service tool.
Unmanaged Gigabit PoE+ switches
B&R: The modular X90 control and I/O system B&R: The can now be equipped with condition monitoring functions. Problems can be detected in their early stages and corrected before they result in unplanned downtime. Condition-based predictive maintenance can maximize machine availability and save the cost of outages and unplanned service calls. The X90 module allows operators to continuously monitor the status of mobile equipment. The results help determine exactly which components require maintenance and when. Typical applications include continuous monitoring of rotating machine components such as hydraulic assemblies, belts, gears and motors. The processed sensor data is also available for further use in the application.
Protocol gateway devices
Antaira Technologies: The LNP-C500G series is a five-port industrial gigabit PoE+ unmanaged Ethernet switch embedded with 4*10/100/1000Tx PoE+ (30W/Port) ports and 1*10/100/1000Tx RJ45 port. The small form factor of this metal casing switch is 50% smaller than the LNP-0500G series which allows for more versatile implementations implementations.. It is designed to ful �ll industrial applications that have small space requirements and need high bandwidth capabilities such as security, ITS transportation, power/utility, and water wastewater treatment plants. This series also works well in any other outdoor application that is susceptible to extreme ambient weather
Advantech: The company has extended Advantech: its protocol gateway product line with the introduction of two new EKI-1221IEIMB & EKI-1221PNMB Protocol Gateway Series for protocol conversion. These new protocol gateway devices support protocol conversion from Modbus TCP to EtherNet/IP, and Modbus TCP to PROFINET.
industrial ethernet book
11.2017
They provide a cost-effective solution and enable seamless connection between different devices with different protocols, and also provide a high level of device management ef �ciency. The EKI-1221IEIMB and EKI-1221PNMB are designed for reliable protocol extensibility and seamless integration with existing network devices. They offer a solution for ef �ciently converting data from legacy devices and reduce the possibility of costly software programming errors. With the addition of these protocol gateway devices into existing network infrastructures, customers can build a seamless data path between otherwise incompatible network devices and extend their useful life.
own power supplies and are easily con �gured and commanded through the PLC’s existing software, eliminating the need for a separate plug-in card controller. The embedded Ethernet switch in the networked drives provide a network connection for additional devices and eliminates the need for an external Ethernet switch. DLR topology provides a fault tolerant connection that can detect a break in the network and redirect the network traf �c, maintaining communication and system up-time.
IP65 Gigabit switches
to connect unattended retail terminals and remote devices in third-party locations. It is also applicable for systems migrating to LTE technology needing to connect to legacy devices. In an effort to future-proof applications and protect investments, SmartStart provides fallback to 3G/2G technologies to ensure that connectivity is reliable in areas where LTE is still under development. The SmartStart LTE router stands out in the market when compared to similar LTE routers. While other M2M devices are hindered by carrier-specific support limitations, such as only Verizon, only AT&T or only EMEA. Similarly, SmartStart solves issues concerning LTE Cat 4 radio overkill, �xed power input, nonexistent I/O, nonexistent Wi-Fi, annual software licenses and more.
I P n r d o u d s u t c r y t N e w s
ONF Certi�ed OpenFlow switch Industrial edge appliance
Lanner: The company is partnering with Lanner: Brain4Net, a SDN/NFV solution vendor and ONF member, to launch ONF-certi�ed network appliances, optimized by the B4N SwitchOS. The network appliances in this collaboration have successfully completed the certi �cation process under OpenFlow Conformance Testing Program at the University of New Hampshire InterOperability Laboratory (UNH-IOL), and received the OpenFlow Version 1.3.4 Switch Conformance Test Report. Lanner’s participating x86-based appliances FW-8894 and NCA-5510, along with B4N SwitchOS have become the �rst OpenFlow switches that have passed extensive rounds of testing and are able to guarantee the highest level of product conformance with OpenFlow specifications as well as the ecosystem-readinesss deployment. ecosystem-readines
Ethernet-based controller/drives
Advanced Micro Controls: An Controls: An embedded switch has been added to its line of Ethernet-based integrated stepper controller/drives. It has been designed to integrate integrate with Allen Bradley PLCs using the Common Industrial Protocol (CIP) for communication, control and data gathering. The embedded switch, added to the company’s EtherNet/IP integrated stepper drives, offers support for Device Level Ring (DLR) installations to provide a fault tolerant connection. AMCI’s powerful AC line powered stepper motor controller/drives are self contained with their 11.2017
Kyland Technology: Technology: A total of six managed IP65 switches, speci �cally designed for train networks, can also be deployed in other applications in harsh environmental conditions. Since the devices of the 86xx series support routing, both subnets can be formed and coupled with each other. The switches have four Gigabit uplinks (10/100/1000 BASE-TX) and eight, 16 or 24 Fast Ethernet ports (10/100 BASE-TX) with M12 technology. Terminal devices can be powered with PoE/PoE + via data lines. Different redundancy protocols and security mechanisms ensure high-availability and secure data communication. A passive bypass function guarantees that networks remain functional even at multiple points of failure. Further features of the switches, which can be put into operation according to the plug-andplay principle, include high shock and vibration resistance, almost complete insensitivity to electromagnetic interference and a temperature range of -40° to + 70° C. The switches provide industrial approvals such as EN 50155 and EN 45545, and have a metal housing intended for wall mounting.
Opto 22: The 22: The enhanced groov industrial edge appliance now offers OPC-UA drivers for AllenBradley and Siemens PLCs, along with support for MQTT protocol communications. Added to the groov View software for web and mobile visualization and the open-source Node-RED development environment, the new release offers engineers, technicians, and developers a comprehensive set of tools for edge deployment in industrial environments. These new embedded capabilities are made possible through forging close partnerships with technology providers Inductive Automation and Cirrus Link Solutions, and are part of the Ignition Edge On board program.
SmartStart LTE industrial router
Smart HART temperature transmitter
B+B SmartWorx: SmartWorx: The SmartStart, industrialgrade Wi-Fi-capable LTE machine-to-machine (M2M) router is both cost-effective, and carrieragile. SmartStart addresses the growing � exibility exibility needs of service providers and OEMs struggling
Moore Industries: Industries: A new member of its Associated Intrinsically-Safe (AIS) family of products has been enhanced with the release of the THZ3 compact Dual Input Smart HART Temperature Transmitter in DIN Rail Mount housing with Associated IS sensor connections. The intrinsically-safe -AIS option allows direct connection of sensors located in hazardous areas since it includes an internal intrinsicallysafe barrier in the front end of the THZ3. The Universal mounting bracket easily snaps on
industrial ethernet book
47
industrial computers provide modern visualization and data aggregation for smart manufacturing. The computers use an open architecture design, allowing users to install software speci�c to their applications.
s w e N t c u d o r P
Connectivity software for IIoT
variety of management systems installed including climate control systems, lighting, sensors of various types, building PA systems, and security systems. In the past, each of these systems would have required their own dedicated wiring. Recently, trends have shifted toward utilizing existing direct current (DC) power lines in configurations where these communication lines are shared with the power system.
Fibre cables for Industrial Ethernet and off of 35mm Top Hat DIN-rails and standard relay tracks. The THZ3-DIN with the -AIS option is an associated apparatus suitable for mounting in Non-Hazardous or Class I, Division 2/Zone 2 hazardous locations with sensor input terminals connected to equipment or sensors located in Class I, II, III, Division 1/Zone 0/1 hazardous locations. Installation costs are reduced if an associated apparatus like the THZ3-DIN with -AIS option is used, since the intrinsically-safe barrier is embedded in the receiving device.
Scalable computing for IoT data
Rockwell Automation: Three Automation: Three compute offerings at the device level help operators make faster, more informed decisions closer to the source of information. Each offering allows users to run applications in a Windows 10 IoT Enterprise environment to gain better insight into machines and equipment. The variety of platforms also gives users � exibility exibility to meet individual application needs. The Allen-Bradley ControlLogix compute module allows users to add Windows 10 IoT directly into the Logix system in existing applications and provides high-speed access to ControlLogix data across the backplane. As a result, users can combine Windows applications as close to the point of decision-making as possible. The Allen-Bradley CompactLogix 5480 controller combines Logix5000 control and Windows-based computing in one controller. The controller supports Windows applications, such as data collection, analytics and predictive computations. It is designed for meeting the demands of high-performance production lines and information-driven smart machines. Third, the Allen-Bradley VersaView 5000
48
RTI : Connext : Connext DDS software ensures edge to fog to cloud connectivity for secure and scalable IIoT applications. Connext DDS 5.3 provides connectivity software for building layereddatabus architectures and IIoT systems. Typical IIoT systems require sharing data across multiple networks, from the edge to the fog to the cloud. For example, in a connected hospital, devices have to communicate within a patient or operating room, to nurses’ stations and off-site monitors, to real-time analytics applications for smart alarming and clinical decision support, and with IT health records. This is challenging for several reasons. Built on the Object Management Group (OMG) Data Distribution Service (DDS) standard, Connext DDS 5.3 introduces support for the recently �nalized DDS Security standard. As a result, devices and applications developed with Connext DDS 5.3 will interoperate with those that take advantage of future Connext DDS versions.
Communication over power lines
HARTING: Fiber optic solutions are addressing HARTING: Fiber extremely tough environments. One new solution for high data rates under extreme conditions is an expanded beam cable assembly. As a result, HD-TV is no longer a problem on machines and systems because the fibre is packed in a connector that cannot be affected by dust, water or operation in harsh environments environments. Also, regular dis-connection and re-connection of cabling in these environments is less problematic compared to standard �ber optic cabling. Even extending the length of the optical connection is uncomplicated, and is as simple as connecting an additional cable, with no need to pay attention to the laying direction. Thanks to the hermaphroditic mating face, an additional adapter is not required. As a result, the customer saves time and money, and also the risk of having a mating face other than needed at the end of the cable.
USB smart modules
Renesas Electronics: The Electronics: The new solution consists of a PLC software modem (R9A06G037), which manages the PLC communications, and the RX651 microcontroller (MCU), which controls the audio codec processing. The new solution enables system manufacturers to enhance security systems by incorporating voice capabilities to an existing installation at low cost. For a new installation that includes various sensors as well as voice communication, wiring costs can be reduced by approximately 60 percent while installation and maintenance costs can be reduced up to 40 percent. Facilities such as office buildings have a
Molex: Single port and dual port modules allow Molex: Single for fast charging in automotive and commercial vehicles. The USB Smart Charge Modules are available in both single port and dual port models. Outside of the number of ports, the two models are nearly identical. Each features over-voltage, over-current and short-circuit protection for safety. Both models also are
industrial ethernet book
11.2017
equipped with a 2.4A output current, a battery operating voltage of 9 to 16V, and can operate at temperatures ranging from -40 to 85°C. Additionally, each have an automotive-grade USB and are compliant to Apple MFI.
Support for Precision Time Protocol
Kithara Software: Support Software: Support for the Precision Time Protocol (IEEE 1588 v2) allows for the precise synchronization of network participants with Kithara RealTime Suite. PTP can be used for image data alignment of cameras, determination of exact measurement data or the execution of parallel robotic tasks. With the PTP stack, accurate timestamps can be generated with deviations in the sub-microsecond range for synchronization of PCs. With a connection to GPS, computers can be synchronized on a global scale. To run the synchronization, the best master clock algorithm (BMCA) can be utilized, which will determine the participant with the most accurate system clock within a network and set it as reference for the other participants. With the PTP stack, raw Ethernet as well as IP/UDP can be used as transport layer. For high-precision timestamping, a variety of PTP-compatible network controllers are supported. The priorities can be adjusted with the API.
Single & multitouch web panels
systems from anywhere, at any time. The L1/ C1 automation panels in conjunction with the WebVisu software offer a versatile platform for web-based graphical user interfaces. The web panels use the panels of the L1/C1 device series as a hardware platform. The over 10 different front units from 7" to 21.5" in 16:9 or 4:3 display format, which are available with resistive singletouch or glass front with PCAP multitouch, can be combined with different system units. Variants with powerful 32-bit ARM Cortex-A9 Multicore CPU, Intel Celeron or Core-i CPUs are available. If required, front unit and PC can also be operated separately from each other via a single, up to 100 meter long cable for video, touch screen and power supply. Linux, web browser and Java-VM are the basis for the use of the L1/C1 automation panels as a web panel. Web browser and Java-VM support HTML5/CSS and are optimized for communication with web visualizations such as CODESYS Web Visualization, ProconWeb, B & R mapp View, TwinCAT PLC HMI Web, WinCC/Web Navigator etc. Thanks to an integrated tool with graphical user interface, L1/C1 web panels can be easily and intuitively con �gured.
Layer 3 Ethernet backbone family
11.2017
(available for Europe and North America), Wi-Fi, Bluetooth Low Energy, and two Fast Ethernet ports; other interfaces are two protected RS-232/485 serial ports, two CAN bus, two noise and surge protected USB ports, and four isolated digital I/O. ReliaGATE 10-12 is a low power (2W typical) gateway with a wide range power supply (9 to 36VDC) and a wide operating temperature range (-20 to +70°C) making it particularly suitable for demanding applications. The gateway comes with the genuine Oracle Java SE Embedded 8 Virtual Machine and the Everyware Software Framework (ESF), a commercial, enterprise-ready edition of Eclipse Kura, the open source Java/OSGi edge computing platform and middleware for IoT gateways.
Remote connectivity HMI
Belden: To meet the need for increased network Belden: To bandwidth and flexible future-oriented solutions Hirschmann has designed a next generation Layer 3 Ethernet backbone product family: DRAGON MACH4000/4500. Available in two major open variants, they offer a maximum of 80 x 1Gb/s modular ports and 8 x 10G �xed ports. The DRAGON MACH4000 family supports redundant internal power supplies to increase device availability, and low-cost future expansion is easy thanks to spare slots for a total of 48 additional ports in copper or �ber.
IoT gateway portfolio
CANNON-Automata: Web panels are becoming CANNON-Automata: Web more and more important in the context of Industrie 4.0. Web-based visualization visualizationss provide access to the user interface of machines and
P r o d u c t N e w s
Eurotech: A new ReliaGATE 10-12 gateway with Eurotech: A integrated LTE connectivity has been announced including two expansion modules for extended I/O capabilities and LoRa LPWAN connectivity. The expanded IoT offering features LTE connectivityy for industrial and lightly rugged connectivit applications. ReliaGATE 10-12 is based on the TI AM3352 Cortex-A8 (Sitara) processor running at 1GHz, with 1GB of RAM, 4GB of eMMC and a useraccessible microSD slot. It provides a wide range of connectivity capabilities, including LTE Cat 1
industrial ethernet book
Mitsubishi: The GT25 Wide HMI features remote Mitsubishi: The connectivity through the company's GOT Mobile option. GOT Mobile provides remote access via web server functionality for production monitoring and system operation. It is designed to monitor controllers using web browsers on d evices such as tablets, phones and personal computers, allowing machine operators, plant managers and maintenance personnel to remotely monitor and verify equipment status at any time from anywhere. The GT25 Wide HMI is equipped with two Ethernet ports to physically separate the information system network in the of �ce from the control system network at the production site, creating safer and more secure network architecture. This high performance HMI also features a built-in sound output interface, which p rovides audio feedback, notifications and verbal instructions to operators.
49
t e n r e h t E e t a v i r P
Harald Blåtand, king of Denmark, Norway and Wireless Harald was the the son of King Gorm the Old and of Thyra Dannebod, and became king of Denmark in the year 958. He introduced Christianity to Denmark and consolidated his rule over Jutland and Zealand. He might be largely forgotten today, had he not had a bad tooth that appeared “blue”.
THIS BAD TOOTH LED TO King Harald’s nickname “Blåtand”, which means Bluetooth. In 1941, Swedish writer Frans Bengtsson included king Bluetooth in his historical adventure novel “The long ships”. 46 years later, a copy of this book landed on the desk of Jim Kardach. He was a design engineer at Intel, working on a “short-link” radio technology. He proposed the name Bluetooth for this new technology, as he hoped that it would unite the different communication protocols into one universal standard, standar d, just like king Harald had united the Scandinavian countries.
Hagalaz und Berkanan This nordic origin is still present in the Bluetooth logo, which combines the old runic symbols Hagalaz und Berkanan.
The runic symb symbols ols Hagal Hagalaz az and and Berkan Berkanan an form form the Bluetooth logo.
While the vikings conquered Scandinavia, Bluetooth went on to conquer the whole world. Today, the Bluetooth Special Interest Group (SIG) has more than 30,000 members, and experts assume that there is an installed base of nearly 10 billion Bluetooth-enabled devices worldwide.
It started with headphones The development of a short-link wireless standard was initiated at Ericsson Mobile, mainly to develop wireless headsets. The engineers opted for short-wavelength UHF radio waves in the globally unlicensed 2.4 to 2.485 GHz industrial, scienti�c and medical (ISM) band. Bluetooth is a packet-based protocol with a master/slave architecture, where one master may communicate with up to seven slaves. The master de�nes the basic clock, with 625 µs
50
A I D E M I K I W : O T O H P
The proud long longships ships of king king Harald Harald and his Viking Vikings s
de�ned as one transmission slot. The master transmits in even slots and receives in odd slots, for the slaves it works the other way around. To ensure a reliable connection, Bluetooth uses frequency-hopping spread spectrum (FHSS), rapidly switching the carrier frequency channels in a sequence that is known to both transmitter and receiver. The inventors of this technology are the Austrian actress Hedy
Lamarr, who had � ed ed from Nazi Germany, and composer George Antheil. They developed this method to make US forces radio communications harder for enemies to detect or to jam. Bluetooth divides transmitted data into packets, and transmits each packet on one of 79 designated Bluetooth channels. Each of these channel has a bandwidth of 1 MHz, and Bluetooth hops between these frequencies 800 times per second.
industrial ethernet book
11.2017
Bluejay After Sara Du got lost in the mountains, she developed the concept of Bluejay, a combination of software and hardware that is able to �nd missing people. Bluejay is a drone that uses an onboard Intel Edison computer and Bluetooth technology to communicate with both people in need of rescuing and rescuers. While cellular service may fail in such situations, Bluetooth would still function, so the drone could communicate with cell phones and facilitate rescues.
A I D E M I K I W : O T O H P
Hedy Lamarr, contemplatin contemplating g frequency-ho frequency-hopping pping spread spectrum technology
Originally, Gaussian frequency-shift keying (GFSK) modulation was used, which limited the bandwidth to 1 Mbit/s. The introduction of Bluetooth 2.0 in 2004 allowed the use of differential quadrature phase shift keying, increasing the bandwidth to 3 Mbit/s.
U D A R A S : O T O H P
Different �avours With ongoing development, Bluetooth today comes in three different “ � avours”. avours”. Classic Bluetooth, in Basic Rate or Enhanced Data Rate, is still the dominant cable replacement technology. It is what we all use for wireless keyboards, mice, speakers and headsets. Bluetooth Low Energy (LE), introduced in 2010, is optimised to use as little energy as possible. Powered by only a coin-sized battery, it can often last for years. Almost every smartphone or tablet today supports Bluetooth LE. The latest addition is Bluetooth mesh, which was launched this summer. It is intended to make the technology better suited for IoT applications. Classic Bluetooth is a startopology in which all devices are connected to a central hub, which limits the network range to the furthest connected device. In the mesh network, all devices communicate with each other, which makes the area covered by the network almost unlimited.
TrackR While we may not get lost at home, our car keys sometimes do. That’s where TrackR TrackR comes comes in. It creates a virtual � oor oor plan of a users home and helps track frequently misplaced items. After attaching the coin-sized TrackR bravo to keys, wallet or phone phone,, the TrackR app can locate it in seconds. One smart feature is that the app even helps you �nd items that you misplaced outside your home through a crowd-sourced network.
When another TrackR TrackR user is within Bluetooth range of the lost item, the owner will receive a location update. Also, the app records the last known location on a map, so at least you know where to start searching.
P r i v a t e E t h e r n e t
Novalia The Novalia Novalia project project brings touch-based interactivity to virtually any printed material. Paper thin self adhesive touch sensors from printed conductive ink are combined with a microcontroller module that handles processing and Bluetooth communications. Touching the sensors controls apps on a smart phone or laptop. A single CR2016 coin cell powers the system for up to one year. Using this technology, Novalia created what the world had been waiting for a long time: The �rst playable pizza box DJ decks. The Pizza Hut boxes come in a design modelled on a modern DJ set-up. They feature two turntables, a cross-fader, pitch volumes, cue buttons and the ability to ‘rewind’ the music. The decks sync via Bluetooth to the user’s smartphone with DJ software such as Algoriddim’s DJAY DJAY Pro. The sound is produced from the smartphone or computer, which can be linked to external speakers. The DJ decks work by sensing human touch through conductive ink and can differentiate between taps, long presses and even swipes of the �nger in any direction. This allows music and pizza fans to mix and scratch their own DJ sets by tapping and sliding their �ngers over the controls. It’s really a shame that this was only a one-off promotion promotion and limited to just a few of the Pizza Hut restaurants. Let us know if there is interest in a DJ-enabled edition of Industrial Ethernet Book magazine. Leopold Ploner
Beyond wireless speakers So what can Bluetooth do beyond connecting speakers or keyboards to our tablets and PCs? To �nd this out, the Bluetooth SIG organizes the annual Imagine Blue Awards. Designers develop solutions that push the boundaries of wireless connectivity. Here are some creative projects from the Imagine Blue competition. Blue competition.
industrial ethernet book
T U H A Z Z I P : O T O H P
11.2017
51
