fieldbus as “a digital, two-way, multidrop communication link among intelligent and control devices.” It is a bidirectional, half-duplex, digital process control and automation protocol. The Foundation Fieldbus has three layers: Physical layer (PHL) Data link layer (DLL) Application layer (APL). It has an additional layer—layer 8, called the “user layer.” It has a two-level architecture consisting of the lower level H1 and the upper layer H2(HSE). H1 operates at 31.25 kbps, while H2 operates at 100 Mbps. It supports both scheduled and unscheduled communications. It supports interoperability, i.e., devices from different manufacturers can be seamlessly connected. Boolean integer floating point unsigned octet string visible string date, time of day, time difference time value, bit string, null, and packed. Foundation Fieldbus has a two-level architecture: H1 is the lower-level bus that connects the field devices together H2 is the upper-level bus that interconnects the different H1 bus segments. H1operates at a speed of 31.25 kbps, while H2 (HSE) at 100 Mbps. An expanded view of the system from the control room level to the field level is possible by employing H1. Multivariables from each device can be brought to the control room for trend analysis, archival purposes, predictive maintenance, asset management and report generation, etc. Huge reduction in number of wires marshaling panels, number of I/Os, IS barriers, control room size, number of equipments, number of power supplies, downtime. 1. Interoperability of subsystems 2. Function Blocks 3. Control Backbone 4. Standard Ethernet The communication process involves transportation of data and messages from one field bus device to another. The devices may reside on the same link or other links joined by bridges. Devices must have a device tag for proper device identification and a device network address for properly delivering data at the designated device. The Fieldbus model consists of three layers: PHL, DLL and APL. For the Fieldbus model, the APL is divided into two sublayers Fieldbus Message Specification (FMS) Fieldbus Access Sublayer (FAS) FAS maps FMS into the DLL. There is a layer above layer 7-called the “user application layer.” Layers 2 to 7 are mostly implemented in software and termed as the “communication stack.” • Protocol Control Information • Protocol Data Unit • Frame Check Sequence Physical layer interests are signal and waveform shapes, voltage levels, type of wires, etc. The physical layer receives the DL PDU from the data link layer to which are appended the preamble, start delimiter, and end delimiter. This is then converted into physical signal and transmitted on the field bus medium by electrical or optical means. Fieldbus signals are encoded using the Manchester Biphase-L technique. Data is combined with the clock signal to create the fieldbus signal. The Physical Layer receives messages from the communication stack and converts the messages into physical signals on the fieldbus transmission medium and vice-versa. The receiver of the fieldbus signal interprets a positive transition in the middle of a bit time as a logical “0” and a negative transition as logical “1”. The signal is called “synchronous serial” because the clock information is embedded in the serial data stream. The preamble is used by the receiver to synchronize its internal clock with the incoming fieldbus signal. Special N+ and N- codes are in the start delimiter and end delimiter. The receiver uses the start delimiter to find the beginning of a fieldbus message. After it finds the start delimiter, the receiver accepts data until the end delimiter is received. The transmitting device delivers ±10 mA at 31.25 kbit/s into a 50 ohm equivalent load to create a 1.0 volt peak-to-peak voltage modulated on top of the direct current (DC) supply voltage. The DC supply voltage can range from 9 to 32 volts. 31.25 kbit/s devices can be powered directly from the fieldbus and can operate on wiring that was previously used for 4-20 mA devices. Fieldbus network’s shared wiring carries power to devices and signals between devices. Fieldbus is a process control local area network used for interconnecting sensors, actuators, and control devices. When not transmitting, a device draws power from the cable for its internal operation. It also draws an additional 10 mAmps that it "wastes." When the device transmits a high signal, it turns off this extra 10 mAmps. This increases the voltage between the wires. When the device transmits a low signal, it draws an extra 10 mAmps from the wires, resulting in a voltage decrease. The signal is above and below the 24-volt non- transmitting level on the network. The data link layer manages transfer of data from one node to another. Addresses, data transfer, their priority, and medium access control are all managed by the data link control layer. DLL ensures that data is shared effectively without collisions, i.e., when one device transmits none other does. The data link layer supports transmitting data as per urgency. There are three levels of urgency URGENT NORMAL TIME_AVAILABLE An urgent message overrides all other message queues. Maximum data sizes belonging to the three data types are 64, 128, and 256 bytes, The most important job of the data link layer is medium access control of the field bus devices. A link or segment is the particular part that shares the physical layer signal at the same time. A device, at a given instant of time, is allowed to use the medium (link) by proper software programming. A link active scheduler (LAS) controls this medium access in the data link layer. LAS and Device Types
Foundation Field bus devices are classified into
BASIC DEVICE (BD)
LINK MASTER (LM)
Bridge
BASIC class devices cannot become LAS, while LM class
devices can. A Bridge class device can become LAS in addition to its original functionality to connect different links. In a link, there can be more than one LM; however, only one can act as LAS at any given time. When there are no LAS in a link, LM devices try to acquire the LAS role, but the one with the least node address wins this contention. Maintain a live list of devices Distributes time on the bus for scheduling Controls traffic on the bus (Bus master function) Grants right to transmit to all devices Polling method – sequence according to predefined schedule Time slot method – Fixed time interval Use free time for asynchronous transfers CD schedule contains a list of activities that are carried out by LAS in cyclic communication. The schedule is prefixed. Thus, at some precise point of time, LAS sends a CD message to a specific field bus device to put its data on the bus. The device then publishes its data on the bus and it goes to the subscribers. The CD schedule is the highest priority job of the LAS. The other jobs are carried out between the scheduled transfers. “Live list” refers to the devices on the bus that responds to the PT issued by LAS. Devices may be added/deleted to/from the field bus as per the requirement. A device may also go off the list, if it goes bad. It is the responsibility of LAS to maintain and update the list of live devices on the list. LAS probes at least one node (i.e., one address) after it has completed one cycle of sending PTs to all the devices residing in the live list. A device may be added to the bus at any time. LAS periodically sends a PN message to the addresses not on the live list. If a device is detected at the node, it immediately sends back a probe response message and the device is added to the live list by the LAS. LAS also confirms the device by sending it a node activation message. LAS removes a device from its live list if it does not respond to the PT or returns the same to the LAS consecutively for three successive tries. Whenever a device is added or removed from the live list, LAS immediately broadcasts the changes in the live list to all the devices on the bus. Thus, each link master on the segment maintains a current and updated copy of the live list. A TD message is broadcast on the fieldbus by the LAS. This ensures that all the devices on the bus have exactly the same data link time. Scheduled cyclic communication on the bus and scheduled function block executions are based on such TD message information so that exact time synchronization is always maintained. A segment or link has more than one link master. In case one LAS fails, another link master will take over. This will ensure that communication on the bus is not disturbed. Thus, the field bus is designed to be “fail operational.” Devices on a field bus are identified by a DL-address. It consists of three fields: link, node, and selector lengths—16, 8, and 8 bits. A link address identifies a link and if communication is between the same link, the link address is omitted. When a message goes from one link to another, only then the link address is inserted. The content of the node field (8 bits) gives the address of the node in a link. The selector field gives the device an internal 8-bit address. It identifies a virtual communication relationship (VCR). When a VCR is connected to another VCR, it is identified with Data Link Connection End Point. Data Link Service Access Point is used when a VCR is not connected to another VCR but can send/receive messages. Foundation Field bus devices have node addresses in the range of 0X10 to 0XFF, which are classified into Link Master (LM) range, BASIC range, default range, and temporary range. LAS has a node address of 0X04, while a temporary device such as a handheld communicator has address in the temporary range. When a device loses its node address, it can communicate by using one address from the default range. LAS is responsible for synchronizing scheduled communication. Scheduled data transfers are used for regular cyclic transfer of control loop data between devices residing on the field bus. Scheduled communication takes place in a synchronous manner. LAS issues a compel data (CD) to the device when its turn comes to upload data on the bus. The device then broadcasts or publishes its data in the buffer of all the devices connected to the bus. Unscheduled communication takes place in an asynchronous manner Unscheduled data transfer uses either a client–server or a report distribution type of reporting for transferring data. Usually, such transfer scheme is undertaken for user- initiated changes such as Alarm, Operator Data Update, Trend Data Update, Set Point changes , Controller Tuning . The application layer consists of two sub layers: FAS and FMS. FAS manages data transfers FMS encodes and decodes user data The FAS provides services to the FMS with the help of scheduled and unscheduled communications of the DLL. The types of services provided by FAS are described by VCRs.
The VCR can be thought of as equivalent to the speed dial
feature on a memory telephone.
Similarly, after configuration, only the VCR number is
needed to be communicated with another field bus device.
The VCR guarantees that message goes to the specific and
correct partner. When a message is transferred, it goes down through a channel called VCR by adding protocol control information (PCI) before going to the physical wire. A VCR is identified by a device-local identifier called “index” specified in the application layer. A VCR can also be identified from other devices with a “DL- address” specified in the data link layer. A VCR has a memory to save messages. Network management configures a particular VCR by providing it with correct index and DL-address. Thus, no two VCRs can have identical index and DL-address. There are three different types of VCRs available: client–server VCR type
source–sink (report distribution) VCR type
publisher–subscriber VCR type
A fieldbus device has many VCRs which enables communicating with various devices and applications simultaneously . It is a user-initiated one-to-one, queued, unscheduled, prioritized communication between devices on the fieldbus. Queued means that messages are received as they are sent, with message priorities remaining intact. In this method, messages are not overwhelmed as in the publisher–subscriber type. The transfers in this VCR type is flow controlled and has a retransmission scheme in case of corrupted message transfers. Operator-initiated messages such as set point change, alarm acknowledge, tuning parameter change and access, and device upload/download are done in client–server VCR type. A device, when it receives a request from the LAS via PT, sends a request message to another device. The requester is the client, while device that received the request is called a server. A typical example is a human–machine interface (HMI) wanting to read data from a function block. The former is the client and the latter is the server. When the request reaches the server from the client, the former sends the data to the client, which in this case is the HMI. It is used for buffered, one-to-many communications to transfer process critical data such as process variable. Buffering means the last published data on the network is maintained and held until a new data overwrites it. The data producer is called a publisher and the data receiver is called a subscriber. In this VCR type, data can be transferred on a purely periodic basis by properly scheduling CD in the LAS. Unscheduled transmission of information is also possible. An attribute in the VCR would indicate which method is used. A typical example is to connect an output from an analog input (AI) block with a process value input of a PID control block. It is a one-to many, one-way communication without schedule. It is used to broadcast or multicast event and trend reports. The destination address may be predefined or included separately with each report. It is sometimes called the report distribution VCR type. Transfer in this mode takes place in a queued manner. Messages are delivered in the order in which they are transmitted. The transfers are unscheduled and take place in between the scheduled ones. This mode is typically used by field bus devices to send alarm reports to operator consoles. Applications use FMS services to send messages between themselves across the field bus using a standard set of message formats. Message formats, communication services, and protocol behaviour are the services that FMS provides for the user application layer. Virtual field device (VFD) and object dictionary (OD) belong to this model Data communication over the field bus is described by an “object description.” Such descriptions are structured together in OD. Objects: Name of the apparatus, an address, status variables and operating modes, function blocks etc. The object description is identified by its “index” in the OD. Index 0, called the object dictionary header, provides a description of the dictionary itself, and defines the first index for the object descriptions of the User Application. The User Application object descriptions can start at any index above 255. Index 255 and below define standard data types such as Boolean, integer, float, bitstring, and data structures that are used to build all other object descriptions. VFDs are used to remotely view local device data that are described in the object dictionary. An identifier, maintained in a VCR, identifies the VFD. A Foundation Field bus device will have at least two VFDs 1.Management VFD 2.Function block VFD Management VFD contains Network management functions
System management functions
NMIB data includes Virtual Communication Relationships
(VCR), dynamic variables, statistics, and Link Active Scheduler (LAS) schedules (if the device is a Link Master). SMIB data includes device tag and address information, and schedules for function block execution.
Information Base (IB)
FMS provides different services to access different FMS objects. variable access event management context management domain management program invocation OD services A variable is a place where a data is stored. An event is used for notifying that an application has detected something important. Failure, data update, and alarms are examples of events. They are used to establish and release VCRs with and determine the status of, a VFD. A continuous memory area is referred to as a domain which is a program area or a data area. A client can download a data to a domain or upload a domain content via FMS services. A data processing function to be managed from other applications is referred to as a program. It is designed for PLC ladder programs USER LAYER BLOCKS The Fieldbus Foundation has defined a standard User Application based on “Blocks. Blocks are representations of different types of application functions. Resource block Function block Transducer block. Devices are configured using Resource Blocks and Transducer Blocks. The control strategy is built using Function Blocks. The Resource Block describes characteristics of the fieldbus device such as the device name, manufacturer, and serial number.
There is only one Resource Block in a device.
The algorithm within the resource block
monitors and checks the device hardware performance. Function Blocks (FB) provide the control system behaviour. The input and output parameters of Function Blocks can be linked over the fieldbus. The execution of each Function Block is precisely scheduled. There can be many function blocks in a single User Application. Functional blocks are classified as
Basic: A standard block as specified by
fieldbus foundation Extended: An enhanced block for including additional parameters Custom type (Flexible): An open block or vendor specific block meeting the needs of specific process requirements A flexible Function Block (FFB) is a user defined block. The FFB allows a manufacturer or user to define block parameters and algorithms to suit an application that interoperates with standard function blocks and host systems Function blocks can be built into fieldbus devices as needed to achieve the desired device functionality. For example, a simple temperature transmitter may contain an AI function block. A control valve might contain a PID function block as well as the expected AO block. Thus, a complete control loop can be built using only a simple transmitter and a control valve Ten standard basic Function Blocks for process control and measurement Enhanced Function Blocks for advanced control I/O interface to the outside world A schedule building tool is used to generate function block and Link Active Scheduler (LAS) schedules. The schedules contain the start time offset from the beginning of the “absolute link schedule start time.” The absolute link schedule start time is known by all devices on the fieldbus. Relationships between the absolute link schedule start time, LAS macrocycle, device macrocycles, and the start time offsets. A “macrocycle” is defines as a single iteration of a schedule within a device. System Management in the transmitter will cause the AI function block to execute at offset 0. At offset 20 the Link Active Scheduler (LAS) will issue a Compel Data (CD) to the AI function block buffer in the transmitter and data in the buffer will be published on the fieldbus. At offset 30 System Management in the valve will cause the PID function block to execute followed by execution of the AO function block at offset 50. The pattern exactly repeats itself assuring the integrity of the control loop dynamics. Note that during the function block execution, the LAS is sending the Pass Token message to all devices so that they can transmit their unscheduled messages such as alarm notifications or operator setpoint changes. For this example, the only time that the fieldbus can not be used for unscheduled messages is from offset 20 to offset 30 when the AI function block data is being published on the fieldbus. Foundation Field bus supports an application clock distribution function. It is usually set and adjusted to local time of the day or to some Universal Coordinated Time. System management contains a time publisher that periodically sends an application clock synchronization schedule message to all connected field bus devices. The data link scheduling time is sampled and sent with the application clock message so that the receiving devices can adjust their local application time. Between synchronization messages, application clock time is independently maintained in each device based on its own internal clock. Application Clock synchronization allows the devices to time stamp data throughout the fieldbus network. If there are backup application clock publishers on the fieldbus, a backup publisher will become active if the currently active time publisher should fail. A basic requirement of process control applications is that precise cyclic updates of process variables should be possible, to ensure good quality continuous control. Generally the number of such tasks in the system remains more or less fixed. Apart from these, communication tasks related to sporadic events, such as alarm reporting and operator changes of set points, must be scheduled. The LAS therefore organizes its overall schedule communication tasks in the system in “Macro Cycles”. The duration of each Macro Cycle is further subdivided into a number of “Elementary Cycles”.
Each EC within an MC begins with the set of
periodic tasks that is to be scheduled within that EC according to its update time period. The EC is chosen to be of such a duration that even after processing of the periodic tasks some time is left for servicing aperiodic tasks, should it be necessary, due to the occurrence of some event in the system. Simple example of a system containing two devices requiring cyclic updates. The update requirements of the two devices are 1 sec. and 0.5 sec. respectively. The LAS sets the EC period as equal to the shortest update time requirement (0.5 Second. in this case). Similarly, the longest update time sets the MC period (1 Second. in this case). The CD for Device 1 is generated at the beginning of each Elementary Cycle and the CD for Device 2 at the second time slot of alternate Elementary Cycles. In the 'free time' in each Elementary Cycle the LAS transmits PT's to devices on the Fieldbus segment in turn, allowing them to transmit unscheduled information. This is the unscheduled portion of the Elementary Cycle. There may be insufficient free time for all Devices to receive a PT before the end of the Elementary Cycle. In this case the LAS continues from where it left off in subsequent cycles. Note that the time available for unscheduled traffic varies from one Elementary Cycle to another. For example in the first EC of an MC in the example, both periodic updates takes place, while in the second EC only one does, since the update requirement of device 2 is lower. For a device to work properly on a field bus, two requirements must be met The device must have a unique network address and a physical device tag. Network address assignments are done by the configuration tool using system management services. Assignments of network address follow these steps: Unconfigured (new to the network) devices join the network at one of the four special default addresses. A configuration tool chooses a used permanent address and assigns the same to the device using system management services. The same configuration tool will then assign a physical device tag to the device using system management services. The above procedure is followed for all new devices that want to have their entry into the network. These newly entered network devices store their physical device tag and node address in non-volatile memory. This procedure ensures the devices retain their separate identifications even in case of power failure or system shutdown. A device or a variable can be traced with the help of tag service. System management supports such a service. When a “find tag query” is broadcast to all the connected field devices, each of them starts searching its VFD for the requested tag and returns back all the required information. In case the tag is found (it includes network address, VFD number, VCR index, and OD index), the complete path is known and the host or maintenance device can then access data from the tag. The transducer block knows the details of I/O devices and how to actually read the sensor or change the actuator and switches.
The transducer block provides the sensor value to the
function blocks and/or makes the change in the output as dictated by the function block.
Transducer blocks can also perform calibration and
linearization. Transducer blocks are defined to decouple function blocks from the local input/output functions required to read sensor hardware and command effector hardware. This permits the transducer block to execute as frequently as necessary to obtain good data from the sensors without burdening the function blocks that use the data. It also insulates the function block from the manufacturer specific characteristics of an I/O device. It provides the local input/output functions needed to read sensors and to command actuators, displays, or other output hardware. It's the link between the physical world of sensors and actuators and the "data world" of process control. The transducer block contains information such as calibration data, sensor type, materials of construction, and in many cases the health and operating status of actuators and sensors. The following additional objects are defined in the User Application: Link Objects define the links between Function Block inputs and outputs internal to the device and across the fieldbus network. Trend Objects allow local trending of function block parameters for access by hosts or other devices. Alert Objects allow reporting of alarms and events on the fieldbus. Multi-Variable Container (MVC) Object serves to “encapsulate” multiple Function Block parameters in order to optimize communications for Publisher-Subscriber and Report Distribution transactions. View Objects are predefined groupings of block parameter sets that can be displayed by the human/machine interface. The function block specification defines four views for each type of block. In Foundation Field bus technology, a device is provided with three device support files to ensure interoperability. Two DD files and one capability file. DDs are platform and operating system independent. The DD provides an extended description of each object in the Virtual Field Device (VFD). The DD provides information needed for a control system or host to understand the meaning of the data in the VFD including the human interface for functions such as calibration and diagnostics. Thus, the DD can be thought of as a “driver” for the device. DDs are written in a standardized Programming language called Device Description Language (DDL). Device functionality and data semantics can be described by DDL. This is then compiled with “tokenizer” Software to generate “DD binary” files. A DD binary has two files. a DD binary with extension “.ffo” The second one is a DD symbol list with extension “.sym”. A DD tokenizer is a software tool that converts the DD source input files into DD output files by replacing keywords and standard strings in the source file with fixed tokens. Device Description Services (DDS) is a software for HMI. On the host side, library functions called Device Description Services (DDS) are used to read the device descriptions. A device can be added to the system, and it would work nicely if the DD of this device is added to the host or control system. Note that DDS reads descriptions, not operational values. The operational values are read from the fieldbus device over the fieldbus using FMS communication services. DDS technology allows operation of devices from different suppliers on the same fieldbus with only one version of the host human interface program. There are four levels in the hierarchy universal parameters function block parameters, transducer block parameters, manufacturer-specific parameters. The capabilities file tells the host about the resources a device has in terms of function blocks and VCRs. This enables the host to configure a device offline. A capabilities file has an extension “.cff”. A capabilities file is often called “CFF,” which stands for Common File Format A device on the field bus can be identified in one of the three following ways device identifier (ID) – 32Byte Unique no. – Manufacturer – canot be changed physical device (PD) tag – 32 byte unique name – user –identify a device for specific purpose node (physical) address – unique 1 byte no – user – configuring the network Redundancy is included in the system at different levels to ensure availability of resources in times of breakdown. Redundancy can be added at host level, device level, media level, and network level. Decentralization of operations is another measure of fault tolerance. Decentralization of operations of the loops would ensure a small part of the plant to be out of order in case of single controller failure. Another major advantage of decentralization is localizing the fault. Redundancy at the host or central level is used to ensure high availability and thereby prevent disruption in production and consequent downtime and heavy losses. Host level ties the network and the field level devices together, and any breakdown here may be life threatening for the entire plant. There can be various methods to achieve host-level redundancy: media redundancy, network redundancy, and network and media redundancy. Sensor redundancy is achieved by employing at least two sensors to measure the value of a process variable at a single point. The two sensor outputs are connected to the two input points of the transmitter. With the help of the standard selector block in the Foundation Field bus programming language, the better of the two sensor outputs is selected. In case of failure of the “good” sensor, the other sensor takes over, thereby obviating the need of shutdown. Thus, redundant sensors result in less numbers of shutdowns. Only if both the sensors fail would it result in shutdown. This is an example of two-out-of-two (2oo2) configuration. Transmitter redundancy involves employing several transmitters for accessing the same process point. Foundation Fieldbus uses status bytes for each process variable to select the “good” transmitter output and reject the others. Foundation Fieldbus takes the help of standard selector block for the above. Such a selector block can handle three or even more inputs. When four such transmitters are so used for accessing and connecting the same process point, this is called four-out-of-four (4oo4). Transmitters from different manufacturers are used to eliminate identical types of transmitter failures, thereby increasing transmitter redundancy.