Scheduling for wireless control in single hop WirelessHART networks

Faculty of Engineering Master’s Degree in Electronics

Engineering

Scheduling for wireless control

in single hop WirelessHART networks

Supervisors: Authors:

M.D. Di Benedetto Valeria Ercoli

Alf Isaksson Identification Number:

Karl Henrik Johansson 171448

A.A. 2009/2010

Faculty of Engineering

Master’s Degree in Electronics Engineering

Scheduling for wireless control

in single hop WirelessHART networks

Supervisors: Authors:

M.D. Di Benedetto Valeria Ercoli

Alf Isaksson Identification Number:

Karl Henrik Johansson 171448

A.A. 2009/2010

I would like to thank some of the people who made this work possible, feasible and plea- surable.

A special gratitude to Alf Isaksson, my supervisor at ABB, for his kindness, patience, motivation, enthusiasm, and immense knowledge.

I would like to express my thanks to Karl Henrik Johansson, my supervisor at KTH, for his detailed review and constructive comments, and for having involved me in this interesting project.

I wish to express my warm and sincere thanks to my home university supervisor Maria Domenica Di Benedetto. I will always be greatly indebted to her for providing me with the stimulating opportunity to make my master thesis in Sweden.

I am especially grateful to Dr.Alessandro D’Innocenzo for his constant support and encouragement during these years.

Finally, I would like to thank my family and friends for giving me happiness and joy

during my difficult moments.

Key words : Automatic process control, WirelessHART, controlled variables, con-

troller, fieldbus, network reliability, performance analysis, PID control, process automa-

tion, scheduling algorithms.

Contents

1 Introduction 1

1.1 Outline of the thesis . . . . 2

1.1.1 Chapter 2:WirelessHART . . . . 2

1.1.2 Chapter 3:Scheduling Theory . . . . 3

1.1.3 Chapter 4:Automation System 800xA . . . . 3

1.1.4 Chapter 5:Process Control . . . . 3

1.1.5 Chapter 6:Scheduling of Wireless Control . . . . 3

1.1.6 Chapter 7:Conclusions and future work . . . . 3

2 WirelessHART 4 2.1 Introduction . . . . 4

2.2 Wireless Standard for Industrial Automation . . . . 4

2.3 WirelessHART Standard . . . . 5

2.3.1 TDMA Data Link Layer . . . . 6

2.3.2 WirelessHART Gateway . . . . 8

2.3.3 WirelessHART Network Manager . . . . 9

2.3.4 WirelessHART Network Schedule . . . . 10

2.3.5 Schedule Strategy . . . . 12

2.3.6 Communication Tables . . . . 13

2.3.7 Graph Routing . . . . 14

3 Scheduling Theory 17 3.1 Introduction . . . . 17

3.2 Scheduling Algorithms . . . . 18

3.2.1 On-line scheduling . . . . 19

3.2.2 Off-line scheduling . . . . 20

4 Automation System 800xA 22

4.1 Introduction . . . . 22

4.2 AC800M Controller . . . . 22

4.3 Evolution of Control Technology . . . . 24

4.4 Clock synchronization . . . . 27

4.5 Fieldbus Standards . . . . 28

4.6 S800 I/O . . . . 30

4.6.1 S800 I/O Station Data Scanning . . . . 33

5 Process Control 35 5.1 Introduction . . . . 35

5.2 PID Control . . . . 35

5.2.1 Proportional Action . . . . 36

5.2.2 Integral Action . . . . 37

5.2.3 Derivative Action . . . . 38

5.3 Cascade Control . . . . 38

5.4 Mid-Range Control . . . . 39

5.5 Split-Range Control . . . . 40

5.6 Ratio Control . . . . 40

6 Scheduling of Wireless Control 42 6.1 Introduction . . . . 42

6.2 Scheduling problem statement . . . . 44

6.2.1 Superframes setting . . . . 46

6.2.2 Communication and control superframe schedule . . . . 46

6.3 Formalization of the scheduling problem . . . . 47

6.4 Scheduling policy . . . . 50

6.4.1 Scenario I . . . . 50

6.4.2 Scenario II . . . . 56

6.4.3 Shared Slots . . . . 59

6.5 Boliden Example . . . . 62

7 Conclusions and future works 66

A Boliden Control Variables 68

Bibliography 71

List of Figures

2.1 WirelessHART network components. . . . 6

2.2 Slot timing. . . . 7

2.3 Communication tables. . . . 13

2.4 Network topologies. . . . . 14

4.1 800xA system network architecture. . . . . 23

4.2 S800 I/O station overview. . . . . 31

4.3 S800 I/O Dynamic Data Exchange. . . . 32

6.1 Industrial network topology [13]. . . . 44

6.2 PID controller. . . . 45

6.3 Example of a generic control loop. . . . 46

6.4 Set of control loops Example I.1. . . . 52

6.5 Superframes Example I.1. . . . 55

6.6 Set of control loops Example I.2. . . . 55

6.7 Superframes Example I.2. . . . 56

6.8 Set of control loops Example I.3. . . . 56

6.9 Superframes Example I.3. . . . 57

6.10 Set of control loops Example II.1. . . . 58

6.11 Precedence graph Example II.1. . . . 58

6.12 Superframes Example II.1. . . . 58

6.13 Set of control loops Example II.2. . . . 59

6.14 Precedence graph Example II.2. . . . 59

6.15 Superframes Example II.2. . . . 60

6.16 Set of control loops Example Shared Slots. . . . 61

6.17 Superframes Example Shared Slots. . . . 62

6.18 Diagram of froth flotation cell. . . . . 63

6.19 Zinc flotation circuit [24]. . . . 64

List of Tables

A.1 Controlled variables for the Garpenberg plant. . . . . 69

A.2 Garpenberg plant: variables to be scheduled in shared slots. . . . 70

Introduction

This thesis is part of the SOCRADES project, a European research and advanced devel- opment project with the primary objective to create new methodologies, technologies and tools for the modeling, design, implementation and operation of networked control sys- tems embedded in smart physical objects. These systems are becoming more important in the new-generation industrial automation field thanks to the many advantages intro- duced by the networks. In fact, the use of a network to connect the devices permits to eliminate unnecessary wirings, reducing the complexity and the overall cost in designing and implementing the control systems. In the last years the fast spread of the wireless technologies has opened new scenarios for the communication in the automation field.

The benefits introduced by the use of wireless communication in the networked control

system are many,first of all the gain in productivity and flexibility,and of course the sim-

plicity and the convenience of the sensors placement. Wireless industrial communications

based on WLAN and IEEE 802.15 standards are in the focus of this kind of research and

development. In particular, wireless sensor/actuator networks (WSN) are to be closely

investigated, as they will definitely foster the mobility and flexibility required in industrial

communication. The natural features of wireless technologies enable greater opportunities

for reconfiguration/upgrading, maintenance and fault tolerance. An industrial application,

as the one considered in this work, will frequently require hard bounds on the maximum

delay allowed. In particular, as the sensors and actuators are part of closed loop control

systems, strict timing requirements apply, ensuring a short response time and an efficient

use of the available radio bandwidth. Thus, algorithms and software that are capable of

dealing with hard and soft time constraints are very important in control implementation

and design, and areas such as real-time systems from computer science are becoming in- creasingly important also in control theory. This combined with the trend of having more functionality being realized in software, make resource scheduling and its effect on control performance a relevant issue.

This work is focused on the study of the problem of finding a good scheduling algorithm in order to manage the exchange of information between sensors/actuators and the gateway and between the gateway and the controller in a WirelessHART networked control system.

WirelessHART is a wireless protocol that provides a low cost, relatively low speed (e.g., compared to IEEE 802.11g) wireless connection. The WirelessHART standard does not give any specification concerning about a particular scheduling algorithm to be used in a WirelessHART network. However, in this Standard there are some requirements to be taken into account. The scheduling theory has been deeply explored in the academic literature and has progressed in recent years due to the strict requirements of real-time systems such as predictability and timing constraints. However, extending this scheduling theory in practice is not so easy cause these theoretical approaches to schedule do not fit well with a real environment in which the notion of task is often completely different from the one defined in theoretical algorithms. In these cases the implementation of a new scheduling algorithm is required.

In this thesis a heuristic, off-line algorithm, priority based is proposed and described in deep with some meaningful examples. The suggested scheduling policy has been applied to two different ideal scenarios. The last part of the thesis deals with a level control problem in a mineral flotation plant and with the possibility to use a wirelessHART network for that plant.The proposed algorithm is applied also to this industrial environment and it is proved to be a good solution to meet the feasibility-delay tradeoff.

Some relevant considerations and conclusions follows.

1.1 Outline of the thesis

1.1.1 Chapter 2:WirelessHART

In this chapter the WirelessHART protocol will be described. The first two sections

give a general introduction to the protocol with the main information and the technical

characteristics of WirelessHART. In the third section a more exhaustive description of

the communication protocol is given: the structure of the MAC protocol (Medium Access

Control),the devices and the network resources specification and in particular scheduling and routing are deeply explained.

1.1.2 Chapter 3:Scheduling Theory

This chapter is an overview of the basic scheduling algorithms of the academic literature suitable for sensor networks. Both on-line and offline algorithms are analyzed.

1.1.3 Chapter 4:Automation System 800xA

In this chapter the industrial IT System 800XA process automation system is described.In particular AC800M controller is presented since it is the most current controller series used within all of the ABB and it provides modern communication features.

1.1.4 Chapter 5:Process Control

This chapter will deal with components required to build complex automation systems using the bottom up approach. The key component is the PID controller and it will be described in Section 5.2. Other important control principles such as cascade control, mid-range control, split-range control and ratio control will be discussed, respectively, in Sections 5.3, 5.4, 5.5, 5.6.

1.1.5 Chapter 6:Scheduling of Wireless Control

In this chapter is presented the proposed scheduling algorithm.The performance of the algorithm are evaluated from the viewpoint of the feasibility and delay by simulation on several ideal scenarios.The proposed approach is applied also to a real industrial environ- ment that is Garpenberg mineral flotation plant.

1.1.6 Chapter 7:Conclusions and future work

The work concludes with a statement of future work.

WirelessHART

2.1 Introduction

NOTE: IN THIS CHAPTER...

2.2 Wireless Standard for Industrial Automation

Wireless technologies give several advantages to industrial automation in terms of gain in productivity and flexibility. Industrial sites are often harsh environments with stringent requirements on the type and quality of cabling. Moreover they can easily require many thousands of cables and it could be difficult to engineer additional wires in an already congested site. Thus wireless communication can save costs and time. At the same time it improves reliability with respect to wired solutions by means of several mechanisms of diversity, such as space diversity, frequency diversity and time diversity. Furthermore the ad-hoc nature of wireless networks allows for easy setup and re-configuration when the network grows in size. Moreover where sensors and actuators are mounted on moving parts, hard-wiring requires complex mechanical solutions that are costly and may limit the freedom of movement of the part and present a potential cause of failure.

As sensors and actuators are part of closed-loop control systems, an industrial application

will require hard bounds on the maximum delay allowed during the communication, so

strict timing requirements apply. Another requirement is the coexistence of the network

with other equipment and competing wireless systems. The WirelessHART standard has

been released to fulfill all these demands.

2.3 WirelessHART Standard

WirelessHART is a wireless mesh network communication protocol for process automation applications, including process measurement, control, and asset management applications.

It is based on the HART protocol, but it adds wireless capabilities to it enabling users to gain the benefits of wireless technology while maintaining compatibility with existing HART devices, tools and commands.

Each WirelessHART network includes three main elements:

• Field Devices that are connected to and characterize or control the Process or Plant Equipment. All network devices, including field devices, must be capable of routing packets on behalf of other devices.

• A Gateway which connects the WirelessHART network to a plant automation net- work, allowing data to flow between the two networks. It enables communication between Host Applications and field devices that are members of the WirelessHART network. Every WirelessHART network includes one Gateway that, in turn, has one or more network access points. They can be used to improve the effective through- put and reliability of the network, as more packets per second through the network are possible and the network is resistant to the failure of a single access point. It is important to notice that a network access point is not directly connected to the process, it is part of the Gateway.

• A Network Manager that is responsible for configuration of the network, schedul- ing communication between network devices, management of the routing tables and monitoring the health of the WirelessHART network. While redundant Network Managers are supported by the standard, there must be only one active Network Manager per WirelessHART network.

In the diagram in Figure 2.1 the WirelessHART network is connected to the plant automa-

tion network through a gateway. The plant automation network could be a TCP-based

network, a remote I/O system, or a bus such as PROFIBUS. The gateway is connected

to the WirelessHART network through network access points that increase the through-

put and improve the overall reliability of the network. All network devices such as field

devices and access points transmit and receive WirelessHART packets and perform the

basic functions necessary to support network formation and maintenance.

Figure 2.1: WirelessHART network components.

Devices can be deployed in a star topology, that is all devices are one hop to the gate- way, to support a high performance application, a multi-hop mesh topology for a less demanding application, or any topology in between. These possibilities give flexibility to WirelessHART technology enabling various applications (both high and low performance) to operate in the same network.

WirelessHART specifies the use of IEEE STD 802.15.4-2006 compatible transceivers op- erating in the 2.4 GHz ISM (Industrial, Scientific, and Medical) radio band. The radios employ DSSS (Direct Sequence Spread Spectrum) technology and channel hopping to guarantee security and reliability. Communications among network devices are arbitrated using TDMA (Time Division Multiple Access) that allows to schedule link activity.

2.3.1 TDMA Data Link Layer

WirelessHART uses TDMA and channel hopping to control access to the network and to coordinate communications between network devices. The basic unity of measure is a time slot which is a unit of fixed time duration commonly shared by all network devices in a network. The duration of a time slot is sufficient to send or receive one packet per channel and an accompanying acknowledgement, including guard-band times for network wide-synchronization. The WirelessHART standard specifies that the duration of the time slot is equal to 10 ms.

The TDMA Data Link Layer establishes links specifying the time slot and frequency where

communication between devices occurs. These links are organized into superframes that periodically repeat to support cyclic and acyclic communication traffic.

All devices must support multiple superframes: different superframes may have lengths that differ from each other and additional superframes can be enabled or disabled accord- ing to bandwidth demand. Slot size and the superframe length (in terms of number of time slots) are fixed and form a network cycle with a fixed repetition rate. However, a superframe is fixed while it is active but its length can be modified when inactive.

Links may be dedicated or shared. Only two devices are assigned to a given dedicated slot, one being the source and the other being the destination. A communication transaction within the slot supports the transmission of a DLPDU (Data-Link Protocol Data Unit) from the source followed right away by the transmission of an acknowledgment by the addressed device.

Otherwise links may be shared between multiple sources, using contention-based access as collisions may occur within a shared slots when more than one source try to convey a packet within the same slot and channel. If a collision occurs, the destination device will not be able to successfully receive any source’s transmission and will not produce acknowledgement to any of them. To reduce the probability of repeated collisions, source devices shall use random back-off delay when their transmission in a shared slot is not acknowledged. Shared slots are allocated to provide base bandwidth and elastic bandwidth utilization while minimizing power consumption.

For TDMA communications to be successful and efficient, all transactions have to occur in slots following specific timing requirements thus synchronization of clocks between devices in the network is critical. In particular, the network devices must have the same notion of when each time slot begins and ends, with minimal variation.

Figure 2.2: Slot timing.

In this way, transmission of the source message can start at a specified time after the

beginning of the slot, allowing the source and the destination to set their frequency channel and enabling the receiver to begin listening on the specified channel. It must start to listen before the ideal transmission start time and continue listening after that ideal time due to a tolerance on clocks. Once the transmission is complete, the communication direction is reversed and the destination device indicates whether it received the source’s DLPDU successfully or with a specific class of detected errors, by transmitting an acknowledgement (see Figure 2.2).

To enhance reliability, channel hopping is combined with TDMA. It is a mechanism of frequency diversity that allows to reduce interference from other sources and multi-path fading effects. At the same time channel hopping provides channel diversity, that is each slot may be used on multiple channels at the same time by different nodes.

NOTE: TIME KEEPING (DATA LINK LAYER)

2.3.2 WirelessHART Gateway

The WirelessHART Gateway is functionally divided into a Virtual Gateway providing a sink or source point for the network traffic and one or more Access Points that provide the physical connection into the WirelessHART network. If the gateway is made up of more than one access point, the Network Manager will schedule communication traffic through all of them.

The Gateway must provide the time synchronization messages to other network devices, so the clock information ripples downward from the top of the network hierarchy to the bottom, that is from the gateway to field devices. The virtual gateway communicates to any field devices through network access points, so it must have a path to every device in the network. On the other hand it can communicate directly with the Network Manager, but this is an external connection. The network manager and the gateway must establish a secure communication channel with each other, and maintain this connection to carry control and data traffic.

The gateway can connect with the host application via various protocols (e.g. Modbus,

PROFIBUS) based on different physical layers. The network access points communicate

with the virtual gateway via a dedicated link or communication port. Moreover, each

access point can support communication with any device to which the network manager

has provided a path. As not utilizing every slot represents wasted opportunities, an access

point should have activity (e.g. transmit or receive) scheduled for every slot. Thus, if the

access points have nothing else to do they should advertise and perform shared listens.

It is important to notice that all communications with the WirelessHART network pass through the gateway which must route packets to the specified destination (network device, host application or network manager).

2.3.3 WirelessHART Network Manager

The Network Manager is central to the overall operation of the WirelessHART network.

It is responsible for the management, scheduling, monitoring, and optimization of com- munication resources of the WirelessHART network. It manages both the WirelessHART network and the network devices. To perform its complete set of functions it needs con- figuration and setup information about the network devices that it reads from the devices themselves, information about how the network is going to be used, and feedback from the network about its overall health.

There is one network manager per WirelessHART network, and it may be co-located with the Gateway in the same box or located in a completely separate physical box. It is an application rather than a network device, so its location is not restricted by the WirelessHART specification. However, the network manager must have a secure commu- nication channel to the gateway.

The network manager forms the WirelessHART network and establishes routes, initializing and maintaining network communication parameter values. It provides mechanism for devices joining and leaving the network. It is also responsible for managing dedicated and shared network resources, and for allocating communication resources. The allocation of communication resources is referred to as scheduling.

The network manager establishes paths between the gateway and the network devices, but after that it is not involved in communications between host applications and network devices. The gateway is responsible for comparing the destination address of packets with its own address and the network manager’s address. Whenever the gateway receives packets destined for the network manager, it may remove the packet from the wireless network and forward them to the network manager using its secure connection. Packets with other destinations, as well as packets received from the network manager, are routed into the network according to the routing described in the packet.

To generate the scheduling, the network manager combines information it has about the

topology of the network, heuristics about communication requirements, and requests for

communication resources from network devices and applications. In particular, in order to schedule communication resources between network devices, the network manager must know the update rate of each device.

As part of its system functions, the network manager collects network performance and diagnostics about the behavior of the overall network. This information is available to be reported to host-based applications but it is also used to adapt the network to changing conditions. The adaptation includes updating route and schedule information, in order to improve operation of the network while conserving power within devices. Reconfigura- tion of the network may be performed while the network is operating as diagnostics are accessible during run-time.

2.3.4 WirelessHART Network Schedule

A key characteristic of a WirelessHART network is the ability to automatically start up and self-organize. However, before a WirelessHART network can form, a network manager and a gateway must exist and they must have created a private connection with each other.

To initialize the network, the network manager must create the network management superframe and the network graph that is an optimized route map.

NOTE: NETWORK MANAGEMENT SUPERFRAME

Management superframe has priority over data superframes and, following the Wire- lessHART specifications, the network management superframe should be 6400 slots. When the network manager creates the initial superframe, it assigns links in it for the gateway’s access points and configures the gateway. It also assigns a dedicated superframe to the gateway (the gateway superframe), in order to schedule activity of management of the network which access points have to perform (such as listening of the channels to search for new devices needing to join the network). Activating this first superframe the network manager establishes the ASN (Absolute Slot Number, it indicates the actual time that is being used for transmission of a specific packet) 0. The time when the network manager starts the WirelessHART network is said to be the epoch for a specific network.

The network manager is also responsible to generate and to manage the network schedule.

In order to do so, it needs information about the network, the communication require-

ments, and the capabilities of the network devices. Using this information the network

manager is able to adjust the schedule to meet the requirements, and then to tune it by

using the feedback from the operation of the system.

The network manager allocates communication resources in terms of superframes and links.

A link is the full communication specification between adjacent devices in the network, that is the communication parameters necessary to move a packet one hop. Each link includes one time slot, a channel offset (for the frequency hopping), its type (transmit, receive or shared), neighbor information, and transmit/receive attributes. Links are assigned to superframes as part of the scheduling process.

The superframe is a set of slots repeating at a constant rate, these slots are called relative slots, meaning that they are relative to the start of the superframe instead of being referred to the epoch of the network. A frameID is assigned to each superframe. The superframe size, i.e. the number of slots in the superframe, is the period of that superframe, that is how often each slot repeats. In particular, the data superframe length is determined by data scan rate.

Time slots are assigned to devices through links. For a dedicated link there will be a send slot in one device and a receive slot in another device. If the link is shared then there will be a receive slot in one device and one or more transmit slots in several devices, in other words, shared links can have more than one talker and only one listener. When a device has a shared link, it uses a collision-avoidance scheme with a backoff/retry mechanism to handle collisions that may occur.

Using shared links may be suitable when throughput requirements of devices are low, or when the traffic rate is irregular. In these situations, assigning shared links may decrease latency because the network device does not need to wait for dedicated links, but this is true only when chances of collisions are low.

The network manager creates a set of links for each device, it determines when the device’s transceiver needs to wake up, and when it wakes up whether it should transmit or receive.

However the link does not determine what is communicated, it is only providing the

”opportunity” to communicate. A link assignment specifies how the network device shall use a time slot. When a time slot is assigned to a device, the device can perform different actions within that time slot, depending on the type of the associated link: it can attempt to transmit a packet, wait to receive a packet, or remain idle.

All devices support multiple superframes of different sizes. All superframes logically start

in the same place in time: cycle 0, slot 0 of every superframe occurs at the beginning

of the epoch. Thus, time slots in different superframes are always aligned, even though

beginnings and ends of superframes may not be. Multiple superframes can be used to

define a different communication schedule for various sets of devices or to allow the en- tire network to run at different communication rates. In fact, by configuring a network device to participate in multiple overlapping superframes of different sizes, it is possible to establish different communication schedules and connectivity matrices that all work at the same time. But a network device with links in multiple superframes may encounter a link arbitration situation. This may happen when two or more superframes with assigned links coincide in the same absolute time slot. In these cases, the device must operate on the link that has the numerically lowest frameID. For this reason, the gateway superframe should be allocated with a large ID value. It is also required to be 40 slots long, this means that the gateway superframe needs to be a minimum of 400 ms. Additional superframes may also be allocated for event notifications or HART commands issued through host ap- plications. It is important to notice that superframes can be added, removed, activated, and deactivated by the network manager while the network is running.

2.3.5 Schedule Strategy

WirelessHART standard does not give any specification concerning about a particular scheduling algorithm to be used in a WirelessHART network. However, there are some references to be taken into account.

First of all, for all network devices accessed through the gateway, the user has to configure how often each measurement value is to be communicated to the gateway. In order to support multiple superframes for the transfer of process measurements at different rates, the size of superframes should follow a harmonic chain in the sense that all periods should divide into each other, in particular, scan rates should be configured as integer multiples of the fastest update time that will be supported by network devices. For this reason, the supported update rates will be defined as 2 ⁿ where n is positive or negative integer values, for example scan rate selections of 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s (or more).

The scheduling of communications associated with process measurements can be simplified

by defining a superframe for each scan period and developing the schedule by allocating

slots for transmission of measurement data starting with the fastest to the slowest scan

rate. To avoid any conflict between the slots reserved for process measurement and network

management, the length of the network management superframes may be configured to

be an integer multiple of the fastest scan rate and configured to use slots that are not

required for process measurement transmission. In this manner, slots may be allocated

for the transmission of measurement without any conflict with the slots dedicated for management communications.

2.3.6 Communication Tables

Each network device (including field devices) contains tables controlling communication activities and packet buffers, which are used to receive, process and forward packets. The communication tables and the relationships between them are shown in Figure 2.3.

Figure 2.3: Communication tables.

The Superframe Table contains the identifier of the superframe, the number of slots in the superframe, a flag indicating if the superframe is currently activated and a list of links.

The Link Table, in turn, contains a reference to a neighbor which is allowed to communicate with the device, indicating the type of the link, the slot number in the superframe, the frequency hopping channel offset and a flag indicating if the link may be used for receive or for transmit.

The Neighbor Table has a primary importance in the management of device communi- cations. It is a list of all neighbors of the device, which are all devices that the device can directly exchange messages with. The neighbor table includes all the properties and the statistics pertaining to the neighbor of the device, such as basic neighbor identity information, performance and historical statistics and shared slots parameters.

The Graph Table maintains the identifier of the graph, optionally the destination address

and a reference to one or more neighbors. When a graph is used for routing, the list of

neighbors held by the graph table identify those devices that are legal destinations for the

packet’s next hop toward its final destination. For more details about graphs and routing

see the next subsection.

2.3.7 Graph Routing

WirelessHART networks can be configured in various topologies in order to support several applications such as:

• star network, in which there is just one router device (the gateway) that communi- cates with several field devices. It is suitable for a small application;

• mesh network, in which all network devices (including field devices) are router de- vices. A mesh network is a robust network with redundant data paths which is able to adapt to changing environments and more widespread applications.

• star-mesh network, that is a combination of the star network and the mesh one.

Figure 2.4: Network topologies.

In a star network all network devices are connected to the gateway through a single hop, while mesh networks are multi-hop networks, that is, they use two or more wireless hops to convey information from a source to a destination, thus requiring a routing algorithm in order to allow the communication between network devices.

WirelessHART documentation does not specify a routing algorithm, it only describes two methods of routing packets in a WirelessHART network: source routing and graph routing. All devices must support both of them. Source routing specifies a single directed route in terms of devices and links, between a source node and a destination node. The source route is statically specified in the packet itself, that contains the list of devices addresses composing the path toward the destination, thus intermediate devices require no knowledge of the source route in advance. However if one of the intermediate link fails the packet is lost, for this reason source routing should only be used for testing routes, troubleshooting network paths or for ad-hoc communication.

On the contrary, in graph routing the graph route is a directed list of paths (subsets

of directed links and devices) that connect two devices within the network that need to

communicate, allowing to have redundant communication between network endpoints.

All intermediate devices must be pre-configured with graph information that specifies the neighbors to which the packet may be forwarded.

The network manager is responsible to setup and manage all routes and to configure graph information in each network device. In order to create efficient and optimized routes the network manager needs information about the network, communication requirements and the capabilities of network devices. Hence, when devices are initially added to the network, the network manager stores all neighbors entries including signal strength information as reported from each network device. Then it uses this information to build a complete network graph which is an optimized route map, in the sense that possible but subopti- mal links have been removed. In particular, the network graph is optimized in terms of reliability, hop count, reporting rates, power usage and overall traffic load. As the over- all network adapts to changing information, the network manager updates the topology, adding or deleting information in each network device. The network manager contains the network graph and portions of the graph that have been installed into each device.

Once the routing information and communication requirements for each device are known, the scheduling of network resources can be performed for both scheduled upstream and downstream communications.

Graphs are unidirectional, thus there are upstream paths which are used from field de- vices to the gateway, for example for transferring process measurements and alarms, and downstream routes that provide paths from the gateway to field devices, to send control information, such as setpoint changes for actuators.

According to WirelessHART routing requirements, in a properly configured network, all devices will have at least two devices in the graph through which they may send packets, each graph should use a maximum of 4 neighbors as a potential next hop destination, the minimum number of hops to be considered when constructing the graph is 2, the maximum one is 4 and, if there is a one hop path to the gateway it should be used.

Every graph in the network is associated with a unique GraphID, a list of neighbors and the destination’s address, but this one is an optional field since intermediate devices may be merely forwarding the packet along the route path according to the GraphID. To send a packet on a graph, the source device include a GraphID in the packet’s network header.

NEED TO INSERT NPDU STRUCTURE?

In addition to the communication tables mentioned above (see Subsection 2.3.6), in order

to be able to route packets along a graph, a device needs also to be configured with a

connection table containing entries that include the GraphID and neighbor address. The

device routing that packet must perform a lookup in the connection table by GraphID, and

send the packet to any of the neighbors associated with that packet’s GraphID. Once any

neighbor acknowledges receipt of the packet, the routing device may release it and remove

the packet from its transmit buffer. If an acknowledge is not received, the device will

attempt to retransmit the packet at its next available opportunity. This means that, when

a field device does not communicate directly with the gateway, then added communication

slots must be reserved in the schedule for packet routing.

Scheduling Theory

3.1 Introduction

A real-time system is a system in which the correctness of the system behavior depends not only on the logical results of the computations, but also on the physical instant at which these results are produced, in other words, it is a system with explicit deterministic (or probabilistic) timing requirements. Real time systems can be viewed as an important subclass of embedded systems. These are most often subject to limited computation resources as a result of economic considerations. This combined with the trend of having more functionality being realized in software, make resource scheduling and its effect on control performance a relevant issue. A key issue in real-time systems is predictability, i.e.

to be able to anticipate the behavior of the system before run-time, and the guarantee that the system will behave as anticipated at run-time. At the same time, run-time flexibility is a desired feature, as not all run-time events can be completely taken into account in advance. In addition, the choice of scheduling strategy in real-time systems is strongly related to the nature of the timing constraints which have to be fulfilled. As different scheduling schemes provide different levels of, for example, predictability or flexibility, there is usually a trade-off between the ability to handle complex constraints and the level of flexibility provided by the selected scheduling strategy.

NOTE: IN THIS CHAPTER...

3.2 Scheduling Algorithms

Real-time scheduling theory offers a way of predicting the timing behavior of complex multi-tasking computer software, assuming that a real-time system consists of the following components:

• a set of computational and communication tasks {τ ₁ , τ ₂ , ..., τ _n } to be performed fulfilling a number of timing requirements, where a task τ i is a sequence of jobs or operations {J _i,1 , J _i,2 , ..., J _i,k

} for i = 1, ..., n;

• a run-time scheduler (or dispatcher) that controls which task is executing at any given moment;

• a set of resources shared by the set of tasks. All communication and synchronization between tasks are assumed to occur via shared resources.

Each job has a release time and a computation time. The release time is the time in which the job becomes available for processing that requires a computation time c. For a task the deadline is the time interval within which all task’s jobs must finish executing and it is specified relative to the arrival time of the task invocation, thus defining also the corresponding absolute deadline. The purpose of the deadline is to constrain the acceptable finishing time for a task. The task characteristics can be specified by a set β made up of 4 elements {β ₁ , β ₂ , β ₃ , β ₄ }. β ₁ describes precedence relations between jobs, that are represented by means of an acyclic directed graph G = (V, E) where V is the set of jobs and, ∀i, j = 1, ..., n, ∀x = 1, ..., k _i , ∀y = 1, ..., k _j , (ix, jy) ∈ E iff J _i,x must be completed before J j,y starts (notice that the involved jobs can belong to the same task or to different tasks). INSERT FIGURE AND REFERENCES

If there are dependencies between jobs β 1 = prec. If β 2 = r i , then release dates may be

specified for each task. If r _i = 0 for all tasks, then β ₂ does not appear in β. β ₃ specifies

restrictions on the computation time for each job of a task. If β 3 is equal to c i,k

= 1 then

each job has a unit processing requirement. If β ₄ = d _i,k

then a deadline is specified for

the job J _i,k

belonging to the task τ _i . This means that the job J _i,k

must finish within the

time interval d i . Given an arbitrary set of tasks, the corresponding scheduling problem

is to find a schedule of these tasks satisfying certain restrictions and optimizing one or

more performance measures. A schedule is said to be feasible if the temporal constraints

of tasks are met at run-time (e.g. if all tasks are executed within a certain time interval).

A task is periodic if it is time-driven, with a regular release (invocations are all identical and arrive at fixed time instants). The time interval between two successive invocations of the task τ i is a constant T i , and it is called the period of the task. If the relative deadline for a periodic task is left unstated it is usually assumed to be equal to the task’s period.

A task is aperiodic if it is not periodic, it consists of a sequence of invocations which arrive randomly, usually in response to some external triggering event, thus it is event- driven. Sporadic tasks are a special case of aperiodic ones but they have a fixed minimum inter-arrival time. Task invocations may be further categorized by their availability to be preempted while executing. Following these classifications, tasks can be non-preemptive, if task invocations execute to completion without interruption once started, or they can be preemptive if task invocations can be temporarily preempted during their execution by the arrival of a higher-priority invocation. In scheduling theory the notion of priority is commonly used to order access to shared resources such as processors or communication channels. Scheduling algorithms can also be divided in two big classes: off-line or static algorithms and on-line or dynamic algorithms.

3.2.1 On-line scheduling

On-line scheduling algorithms are suitable for event-triggered systems as they provide the capability to handle dynamic on-line events. They require a complex scheduler that has to make decisions about which task to execute at run time, based on the priorities of the task invocations. As it is a priority-based approach, this scheduling policy can be further categorized with respect to the priority, thus determining fixed-priority algorithms and dynamic-priority algorithms. In fixed-priority algorithms the dispatcher statically associates a priority with each task in advance.

Two basic priority assignment rules are the Rate Monotonic (RM) algorithm and the Deadline Monotonic (DM) scheduling. According to RM, tasks are assigned fixed priorities ordered as the rates, so the task with the smallest period receives the highest priority.

Instead, in DM tasks with shorter deadlines are allocated higher priorities. In dynamic- priority scheduling the priority of each task is determined at run-time. Typically this requires a more complex run-time scheduler than fixed-priority scheduling. One of the most used algorithms belonging to this class is the Earliest Deadline First (EDF) algorithm, according to which task priorities are inversely proportional to the absolute deadlines.

Considering a physical plant interacting with a controller that measures some plant signals

and generates appropriate control signals in order to influence the behavior of the plant, another approach is to combine scheduling theory and control theory to achieve higher resource utilization and better control performance. In this case, the on-line scheduler uses feedback to dynamically adjust the control task attributes in order to optimize the global control performance, trying to keep the resource utilization at a high level and distributing the computing resources among the control tasks. In particular, in feedback- feedforward scheduling of control tasks, the dispatcher uses feedback from execution time measurements and feedforward from workload changes to adjust the sampling period of the controller, so that the performance of the closed-loop control system is maximized.

3.2.2 Off-line scheduling

Off-line scheduling algorithms require the programmer to define the entire scheduling prior to the execution. According to this table-driven approach the time line is divided into slots of fixed length (minor cycle) and tasks are statically allocated in each slot based on their rates and execution requirements. The schedule is then constructed up to the least common multiple of all periods (called the hyperperiod or the major cycle) and stored in a table. At run-time, tasks are dispatched according to the table and synchronized by a timer at the beginning of each minor cycle. Given a set of periodic processes the problem to schedule them meeting their deadline and period constraints is known to be NP-hard for one processor, which means that in the worst case an exponential amount of work appears necessary to determine whether a feasible solution exists. In other words, in the worst case an exhaustive search is necessary in order to determine if a schedulable solution exists or not.

In practice, most cyclic executive schedules are derived manually, but they can also be

automated, despite deriving an optimal schedule is theoretically an intractable (NP-hard)

problem. On one hand, off-line algorithms allow to consider and to manage complex

dependencies between tasks and resource contention among jobs when constructing the

static table. Moreover, this policy produce programs that are entirely deterministic, so it

is possible to know which task is executing at any given time. As tasks always execute

in their preallocated slots, the experienced jitter is very small. Furthermore, the entire

schedule is captured in a static table, so different operating modes can be represented

by different tables. On the other hand, this scheduling policy is fragile during overload

situations, since a task exceeding its predicted execution time could generate a domino

effect on the subsequent tasks, causing their execution to exceed the minor cycle boundary.

In addition, off-line scheduling is not flexible enough for handling dynamic situations. In

fact, a creation of a new task, or a change in a task rate, might modify the values of the

minor and major cycle, thus requiring a complete redesign of the scheduling table. So, the

off-line scheduling approach is more suitable for static configuration of systems. Another

potential source of inefficiency is the need to fit all activities into common multiples of the

major and minor cycle (so if an activity does not fit exactly into the schedule it may be

necessary to rewrite the code to make it fit).

Automation System 800xA

4.1 Introduction

The Industrial IT System 800xA is a process automation system that extends the scope of traditional control systems incorporating all automation functions in a single environment, and embracing the principles of real time computing and networking. The 800xA system functionality is divided into a Base System, which is the system base software and a set of options or functions that can be added to the system based on the needs of the process that should be controlled. Controllers are integrated with the system through integration functions. Generally, the 800xA system is used together with the AC800M controller.

NOTE: IN THIS CHAPTER...

4.2 AC800M Controller

Due to its modularity the AC800M controller can be used for a wide range of applications.

It supports industry standard fieldbuses and communication protocols such as Ethernet, PROFIBUS, FOUNDATION Fieldbus and HART, via embedded or external communi- cation interfaces. The AC800M controller supports the S800 I/O, a distributed modular I/O system for communication via PROFIBUS or directly connected to the controller.

INSERT REFERENCE DOC 3BSE038018R5011

In Figure 4.1 the 800xA system network architecture is shown. The automation system

network is a real time LAN (Local Area Network) optimized for high performance, and

it is used for communication between workplaces, servers and controllers. Workplaces

provide various forms of user interaction, whereas servers run software that provides system

Figure 4.1: 800xA system network architecture.

functions. In a cabled network fieldbuses are used to interconnect field devices such as sensors, actuators, and I/O modules, and to connect these devices to the system, either via a controller or directly to a server.

As an alternative a WirelessHART network can be used to interconnect field devices and to connect them to a gateway, which is in turn connected to the controller by means of fieldbuses. The automation system network can be connected to a plant network, such as an office or corporate network, via some form of secure network interconnection such as an isolation device. The nature of the secure interconnection depends on the nature of the plant network and the level of security that is required for the considered application.

The automation system network can also be split into a client/server network and a control

network for larger systems or for systems where network separation is required e.g. for

system integrity reasons. The control network is based on TCP/IP over Ethernet, so it

is a private IP network domain especially designed for industrial applications, and where

addresses are static and must be selected according to a scheme defined by the RNRP

(Redundant Network Routing Protocol). It is a routing protocol developed by ABB which

supports redundant network configurations as it handles alternative paths between nodes

and automatically adapts to topology changes. A redundant network consists of two

fully separate Ethernet networks. Each node has two IP addresses, one on the primary

network, and one on the backup network. Detection of a network failure and a switch over

to the redundant network takes less than one second, with no loss or duplication of data.

Following the RNRP protocol, each node cyclically sends a routing vector as a multi-cast message on both networks. The routing vector indicates which other nodes this node can see on the network. Each node uses received routing vectors to build a table, listing which nodes can be reached on which of the two networks. One of the networks is designated as the primary network, the other one as the backup network. As long as the primary network works, all traffic is sent on that network , only routing vectors are sent on the backup network to verify that it works.

The control network can be a very small network with a few nodes or a large network containing a high number of network areas. Normally, the control network covers one manufacturing plant. A large control network can be divided into subnetworks (network areas), for example to keep most of the time-critical communication within smaller areas, thereby improving performance. Network areas are interconnected by means of RNRP routers. The AC800M controller also has router capability, but since it only has two network ports it can only be a router between two non-redundant network areas. It is not possible to do routing between two redundant network areas by using two AC800M with one on each path. The number of nodes in one control network segment is limited, due to limited routing resources in controller nodes, and to the load generated from RNRP in the controllers.

It is important to notice that communication performance is affected by bandwidth, mes- sage length and cyclic load. In particular, the actual communication throughput for a controller mainly depends on the cycle time of the applications and the CPU load in the controller, rather than the ethernet speed.

4.3 Evolution of Control Technology

The evolution of controls technology can be resumed in the three phases: classical control (in which the process control systems were analog and made up of simple devices with signal formats that were essentially determined by the need for an architecture with a minimum number of costly CPUs), digital control, and networked control.

The milestones of this development were the introduction of negative feedback amplifiers,

field adjustable PID controllers, and especially digital computers. These technologies have

had a huge impact on control theory and its application, and today they are strictly linked

with the PC hardware revolution.

As regard networked control, control systems with spatially distributed components have existed for several decades. However, in the past, in such systems the components were connected via hardwired connections and the systems were designed to bring all the in- formation from the sensors to a central control station. The control policies then were implemented via the actuators, such as valves or motors. Moreover, before digital com- munications was introduced, sensors and actuators were hardwired to their controllers and it was impossible to transmit more than a single process or manipulated variable. In addition, analog signals only traveled in one direction, from the transmitting sensor to the controller or from the controller to the receiving actuator.

As the networking used in automation is predominantly digital, the trend is toward all- digital communications, that makes it possible to extract much more information from each device than was possible using analog signals. The advent of digital communica- tions makes it possible for controllers to be placed away from sensors and actuators, as all information for hundreds of loops and monitoring points could be transmitted to the controller over a single network. Digital communications carry not only I/O like process and manipulated variables but also operational information such as setpoint, alarms, and tuning in both directions to and from the controller. Thus communication enables dis- tributed processing, and some functions can be added not only in controllers but also in field instruments. In this way, thanks to communications, field devices perform not only a basic measurement or actuation but also have features and functions for control and asset management. Moreover, using a digital signal for control there is no analog conversion from the device to the signal wires, and then from the signal wires to the host, which increases the accuracy of the process variable.

A second big benefit of digital communications is the capacity to connect several devices to the same single pair of wires to form a multidrop network that shares a common communication media. Compared to running a separate wire for each device (like in analog communication), this reduces the wiring requirement, especially for plants with large distances and many devices. Hence, the amount of required cables is greatly reduced, allowing hardware and installations savings.

In industrial environment, the set of digital communication protocols used for distributed

control is represented by Fieldbus systems (see Section 4.5 for further information). In

the simplest form of communication, a device such as a host workstation or a controller

is the master that sends requests to read or write a value to other devices such as field instruments, which are called slaves. The slave that was addressed then respond to the request. An example of this master/ slave communication is the HART or the PROFIBUS architecture. In a network with no specific master or slaves such as FOUNDATION Fieldbus the client/server method is used. In this case a device acting as a client requests, and the device acting as a server responds. Another mode of communication is when a device acting as a source transmits a message to a device acting as a sink without any request from the sink. The choice of the communication protocol depends on the particular application as buses are optimized for different characteristics. The common characteristic of Fieldbuses is that they allow many devices to be connected on the same wire and provide the necessary addressing mechanism to support communication with them.

Several Fieldbus manufacturers have recognized also the advantages of Ethernet, which is another standard bus system for industrial applications. These advantages are related to the physical layer, particularly in terms of bandwidth, which can be higher than 100Mb/s rather than up to 12Mb/s for fieldbuses. However both of them can be considered high speed protocol when compared with typical requirements of most industrial applications, where the required data throughput of the network is relatively low, but its reliability needs to be very high. The disadvantage of fieldbus are its higher installation and purchase costs for fieldbus devices. Actuators and sensors are often relatively inexpensive when compared with the cost of the cable used to connect them. Beyond the high installation and maintenance costs, the high failure rate of connectors and the difficulty of troubleshooting them have to be considered.

These are the main reasons why in industrial environments, apart from lower installation

and maintenance costs, wireless systems can offer ease of equipment upgrading and prac-

tical deployment of mobile robotic systems (see Section 2.2). It must be noted that the

common trend in the semiconductor industry has been towards ever more complex inte-

grated circuits with a higher transistors number (thanks to the continuing success of the

Moore’s law) and higher clock frequencies. This trend, in combination with recent tech-

nological advances in MEMS (Micro Electro Mechanical Systems), enables an increasing

integration of devices at a lower cost. However, integrating devices through wireless rather

than wired communication channels has highlighted important potential application ad-

vantages but, at the same time, also several challenging problems for current research. In

fact, one of the main characteristics of wireless networked control is that complexity of

the application lies not in the individual nodes, but in the collaborative effort of a large number of distributed elements. This means that, even if high clock frequencies technol- ogy and wireless data rates of many Mbit/s are available, individual nodes use a restricted amount of computational power and wireless communication protocol with data rates of the order of tens Kbit/s. This observation is quite crucial, as in some sense goes against the dominant trends in both the world of computation and wireless communication, where the aim is to reach high computational power and high data rates. The first reason of this characteristic of networked control is due to the requirements of most applications, that is regular and low frequency transmission of small data packets. Moreover, the distributed nature of the embedded wireless network allows to split the computational power over a collection of wireless devices, rather than relying on a central communication coordina- tor, or at least to perform some functions on the field devices themselves. However, the main reason to use a restricted amount of the possible computation power and low data rates is due to the nature of the wireless communication between devices. In particular, performance of a wireless network has to be optimized with respect to constraints on com- munication bandwidth, contention of communication resources, delay, jitter, noise, fading, and energy usage. Energy conservation is a key requirement in the design of wireless networks. This is mainly due to the limited power availability. In fact, as the speed of embedded processors increases and more peripherals are integrated into a single chip, the applications that run on these devices become more computationally intensive. However, technological advantages of the batteries which power the embedded systems lags signifi- cantly behind, and as a result, power consumption is one of the most important issues for wireless embedded systems. In order to reduce the energy spent in communication, the wireless network should use bounded data rates, as the power spent in communication is the principle source of energy consumption. A good power management technique reduces also long term fading effects and interference. As a consequence of this power management policy devices will transmit with the minimum transmit power level both to save energy and to reduce fading and interference on the shared wireless medium.

4.4 Clock synchronization

Typically a controller will act as time master for the control network and the rest of the

system will be synchronized from this source. The time source can be a controller or one

external time source. It is advisable to use an external time source if it is important that time stamps in the system are possible to compare with time stamps from other systems.

The AC800M supports clock synchronization by four different protocols: CNCP, SNTP, MB300 Clock Sync, and MMS Time Service. The AC800M can send clock synchronization with all protocols simultaneously, but it will itself only use the one configured protocol to receive clock synchronization from another source. One usage of this is to let it receives tim with one protocol and distribute to other nodes with another protocol.

CNCP (Control Network Clock Protocol) is an ABB proprietary master-slave clock syn- chronization protocol for the control network. When using the AC800M controllers CNCP is the recommended protocol for time synchronization to all nodes on the control network that support CNCP.

SNTP (Simple Network Time Protocol) is a standard clien/server oriented time synchro- nization protocol. If the control system needs to be synchronized with a global time master, the recommended method is to use an SNTP server with a GPS receiver. The same holds if the system is made up of more than one control network.

The AC 800M OPC Server supports the MMS Time Service for small systems where no AC 800M is used for backward compatibility with older products. MB 300 Clock Sync is a protocol for clock synchronization of Advant/Master products on a MasterBus 300 network.

4.5 Fieldbus Standards

Fieldbus systems are used as means of communications for serial data exchange between de- centralized devices on the field level and the controller of the process supervision level. All relevant signals such as input and output data, parameters, diagnostic information, con- figuration settings and, for a wide range of applications, the power required for operation can be carried over two wires. Obviously, if a field device has a high power requirement, then this device can be powered externally. Historically, communication between field devices and a control system has been over analog 4-20 mA current loop interfaces. This widely used technology works well and allows accurate transmission of process variable measurements as well as effective closed-loop control.

Fieldbus technology, however, is digital. This brings remarkable simplification to system

architectures and, principally, when digital field instruments are used, significantly more

data becomes available. Technically, Fieldbus is a fully digital and duplex data transmis- sion system, which connects smart field devices and automation systems to an industrial plant’s network. A Fieldbus differs from point-to-point connections, which allow only two participating devices to exchange data. In fact, the key attribute to Fieldbus com- munications is higher speed communications with the possibility of addressing multiple transmitters all on the same field wiring. Since the Fieldbus concept is a computer network specifically designed to support realtime, field sensor/actuator level messaging, most of the Fieldbus systems available today adopt the ISO/OSI 7 layer model, but in a reduced stack architecture.

There are hundreds of different Fieldbus protocols, but not all of them are recognized as standards. Currently, PROFIBUS and FOUNDATION Fieldbus are the accepted Fieldbus standards for the automation industry. Both of them can provide pure digital communi- cations between field devices and the control systems. In terms of Fieldbus organization they are similar with many user groups and support worldwide by the major manufac- turers, whereas their technologies are different in several important areas. ABB supports both PROFIBUS, and FOUNDATION Fieldbus, that are standards of the IEC (Inter- national Electrotechnical Commission). PROFIBUS and FOUNDATION Fieldbus are Fieldbus standards for applications in the manufacturing industry, process automation and building automation.

The PROFIBUS family mainly consists of PROFIBUS-DP and PROFIBUS-PA. The first one is optimized for high speed and simple connection of devices, and it is especially designed for communication between programmable controllers and a distributed I/O level.

PROFIBUS-PA is especially designed for process automation, and it allows sensors and actuators to be connected to the same bus, even in security areas. The transfer rate varies from 9.6Kbit/s to 12Mbit/s.

The FOUNDATION Fieldbus is dedicated to the establishment of a single, open, inter- operable Fieldbus. The standard developed by this Foundation, Foundation Fieldbus, might emerge as one of the world’s dominant Fieldbus protocols for process control in the very near future as this technology seamlessly integrates with Ethernet technology offering high speed and reliable automation solutions for the process industry at affordable costs.

FOUNDATION Fieldbus defines two communication profiles, H1 and HSE. The H1 profile

has a data transmission rate of 31.25 Kbit/s and it is mostly used for direct communica-

tion between field devices in one link (H1 link). The HSE profile with a transmission rate