CHAPTER 1 INTRODUCTION

1.1 SIMULATION OF FOUNDATION FIELDBUS DEVICES Simulation is the imitation of some real thing or process. The act of simulating something generally entails representing certain key characteristics or behaviors of a selected physical or abstract system. Here thedevices which we simulate arefor automation industry. Simulation is very important in automation industry for various factors like: 1. Error reduction 2. Economic Efficiency 3. Time Efficiency 4. Performance Efficiency Process control is the basic need of the automation industry. For process control system we require fieldbus devices. The Foundation Fieldbus devicesprovide several functionalities like fetching the input from sensors; manipulate that input by different algorithms according to our requirement and finally giving the correct output. So in order to design an industry successfully the first thing we need is to simulate the functionalities of foundation fieldbus device. Once the functionalities are properly simulated we can go for the designing different strategies for processing and finally give the optimum design for efficient working of the industry automatically.

1.2 ABOUT THE ORGANISATION Honeywell International, Inc. (NYSE: HON) is a major conglomerate company that produces a variety of consumer products, engineering services, and aerospace systems for a wide variety of customers, from private consumers to major corporations and governments. Honeywell is a Fortune 100 company with a workforce of approximately 128,000, of which approximately 58,000 are employed in the United States. The company is headquartered in Morristown, New Jersey. Its current chief executive officer is David M. Cote. The company and its corporate predecessors were part of the Dow Jones Industrial Average Index from December 7, 1925 until February 9, 2008. The current "Honeywell International Inc." is the product of a merger in which Honeywell Inc. was acquired by the much larger AlliedSignal in 1999. The company headquarters were consolidated to AlliedSignal's headquarters in Morristown, New Jersey; however the combined company chose the name "Honeywell" because of its superior brand recognition. Honeywell has many brands that consumers may recognize. Some of the most recognizable products are its line of home thermostats (particularly the iconic round type), Garrett turbochargers, and automotive products sold under the names of Preston, Fram, and Autolite. Diverse, ingenious, committed and integrated thats Honeywell Technology Solutions Lab (HTSL). A place where technology and people strike a perfect balance to deliver unsurpassed value to customers by providing innovative and total solutions enhancing the comfort, safety, security, efficiency and reliability of the environment they live, travel and work. A SEI CMMI Level 5 companies, this is a place where commitment to quality and the spirit of innovation is intrinsic to its culture.

HTSL believes that to grow, one needs to constantly embrace and adapt to change. Keeping this philosophy in mind, HTSL has come a long way from its early days in 1994, when Dr.KrishnaMikkilineni, the Managing Director of HTSL led the company with about half a dozen people. From being an off-shore development center, today, HTSL provides value to Honeywell businesses through Product Solutions & Analytics, New Product Introduction, Advanced Research and Technology and IT & Business Process Solutions. The Product Solutions team is supported by core engineering functions like Platforms & Solutions specialists, Program Management, Process & Black Belt, Solutions Assurance & ileitis Focus and Strategy and Market Sensing. 1.3 NEED FOR THE PROJECT

Simulation is needed when we are dealing with very critical product in which margin of error is nil. Such an area is automation industry. Once the whole design is implemented it is very difficult to handle any new or unknown error. Because of this we first work in a simulated environment to either eliminate the error else find a way to handle that error. One of the advantages of having foundation fieldbus devices are that they are easy to maintain. Simulation of fieldbus devices are needed because of following: 1. Error Reduction:It is much safer to try different possibilities in simulation environment for optimization of design. Final draft of the design is made (in simulation environment) after testing for all possible errors that might occur in real environment. It helps in reducing the error in industry by 99% 2. Profitable: It is much more economical to try different possibilities in simulation environment for optimized design than in real environment. Only the devices needed according to the final design are purchased. This saves a lot of money for the organization.
3

3. Time Efficiency:It is much faster to try different possibilities in simulation environment for optimization of design. 4. Optimization: By trying different combinations of strategy in simulation we can select the most efficient or optimized strategy for the industry and implement that directly in real environment. 1.4.OBJECTIVES To make the automation industry error free in the real environment. To reduce the cost immensely by implementing the whole idea in simulation rather than directly in real environment.
y

y y

To improve the efficiency of the product by finding the optimized in the design.

CHAPTER 2 LITERATURE REVIEW

2.1 AUTOMATION Automation is the use of control systems and information technologies to reduce the need for human work in the production of goods and services. In the scope of industrialization, automation is a step beyond mechanization. Whereas mechanization provided human operators with machinery to assist them with the muscular requirements of work, automation greatly decreases the need for human sensory and mental requirements as well. Automation plays an increasingly important role in the world economy and in daily experience. Automation has had a notable impact in a wide range of industries beyond manufacturing (where it began). Once-ubiquitous telephone operators have been replaced largely by automated telephone switchboards and answering machines. Medical processes such as primary screening in electrocardiography or radiography and laboratory analysis of human genes, sera, cells, and tissues are carried out at much greater speed and accuracy by automated systems. In general, automation has been responsible for the shift in the world economy from industrial jobs to service jobs in the 20th and 21st centuries. Automation during the 70's and 80'smaynow be obsolete, worn out, or left without spares and support as manufacturers concentrate on newer products. Therefore suppliers of process lines and key equipment who must continue to satisfy customer expectations and keep plant up and running must also develop hardware and software solutions that can modernize legacy control platforms while keeping their functionality intact.

2.1.1 Mechanical Automation After the industrial revolution mechanical automation came into existence as the need of massive plants and factories where synchronization and precision of work were very important like petrochemical plants. Here a small human error may lead to huge losses not only in terms of money but also life. So mechanical automation came into existence where some kinds of alarms, audio or visual, were used to fulfill the purpose. But still this was not sufficient with the increase in the size of the industries which was growing enormously day by day. 2.1.2Software Automation Software industry was growing parallel to the mechanical industry and soon its use and implementation were found everywhere. As the mechanical industry was growing enormous in size mechanical automation was found short to fulfill its need. So came the evolution of software automation where few numbers of technical experts can control and manage the whole industry sitting at one place, in one room. Software automation in the simplest sense is implemented by the use of microcontrollers and a program that contains the logic for it. The programmed logic takes care of the synchronization and precision of the work needed to be implemented. This simple implementation has grown with time and one of such is called control system.

2.2 CONTROL SYSTEM

Control systems execute one or more control functions, which cause the process to operate within the normal operating limits. Control functions can be executed manually or

automatically. Operators supervise the process using the control system interface, respond to its indications and alarms, and, when necessary, use it to act on the process.

2.2.1 Distributed Control System Within the process industry, control functions are used to achieve production and product quality targets, reduce manpower requirements, reduce human errors, and improve process uptime. In the early years, control functions were mostly pneumatic and were physically mounted on control valves, I-beams, and the walls of plants, it was truly distributed control in the field. By the time the first distributed control system (DCS) was introduced in the late 1970s, control functions had been relocated into central control rooms with their long steel panel boards of controllers, indicators, alarm panels, and switches and lights. Despite its name, the introduction of the DCS actually caused control to become further centralized by placing multiple control functions into one microprocessor based controller, thus the requirements for redundant controllers was born. Today we have digital open control systems that are far more robust and capable in terms of performance and diagnostics than their DCS predecessors, but that doesnt mean they can be relied on to perform control and safety functions. 2.2.2 Process Control System In the early days of process automation, the process control system (PCS) consisted of pneumatic transmitters and controllers thatoperated the control valve by adjusting its output air signal to the positioner on the valve. These pneumaticcontrollers were used to perform relatively simple control functions. Over time, the PCS evolved intoprogrammable logic controllers (PLC) and distributed control systems (DCS), which are based onprogrammable electronic (PE) technology. PE technology brought an increased ability to execute

morecontrol functions on a single platform. This processing capability allowed the implementation of statisticalprocess control, predictive control algorithms, and other advanced control techniques, resulting intremendous productivity and quality improvements. The integrity of the PCS hardware has steadily improved over the years with increased internaldiagnostics allowing these systems to be configured to obtain the desired process reliability. The capabilityto implement redundant components throughout the system, including input/output modules and mainprocessors, has further enhanced reliability. Extensive internal and external diagnostics have also beenincorporated into the field device design, providing more rapid fault detection. Today, most process units are highly dependent on automated control systems. Operators rely on the PCS and its operator interface for process information during normal operation, for alarms duringprocess excursions, and for troubleshooting process control problems. The PCS is now so specializedthat typically only a few site personnel are knowledgeable in the control system design details and areresponsible for implementing solutions to optimize the PCS in order to garner improvements in quality, production, and cost. PCS technology provides significant benefits with its capabilities and flexibility, but italso introduces new and more complex failures. This creates an environment where, if administrative controls are not in place, the PCS exists in an almost endless state of flux where control loops areroutinely placed in manual mode, alarms are disabled or reset by operators based on personal choice, andprocess control specialists implement the newest in control algorithms while the process unit is inoperation.

2.2.3 Foundation Fieldbus Devices Automation is the use of control systems and information technologies to reduce the need for human work in the production of goods and services. A complex automated industrial

system- such as a manufacturing assembly line -usually needs an organized hierarchy of controller systems to function. In this hierarchy there is usually a Human Machine Interface (HMI) at the top, where an operator can monitor or operate the system. This is typically linked to a middle layer of programmable logic controllers (PLC) via a non-time-critical communications system (e.g. Ethernet). At the bottom of the control chain is the fieldbus which links the PLCs to the components which actually do the work such as sensors, actuators, electric motors, console lights, switches, valves and contactors. Foundation Fieldbus is an all-digital, serial, two-way communications system that serves as the base-level network in a plant or factory automation environment. It is an open architecture, developed and administered by the Fieldbus Foundation. It's targeted for applications using basic and advanced regulatory control, and for much of the discrete control associated with those functions. Foundation fieldbus technology is mostly used in process industries, but nowadays it is being implemented in powerplants also. This project aims to simulate the foundation fieldbus devices by developing the functional blocks of those devices in the simulated environment.

CHAPTER 3 SOFTWARE AND HARDWARE REQUIREMENTS AND SPECIFICATION

3.1 SOFTWARE REQUIREMENTS Operating System DBMS IDE Other : Windows Server 2008

: MySQL : Microsoft Visual Studio 2008 : Experion PKS (Honeywells)

3.2 HARDWARE REQUIREMENTS Processor/RAM/HDD : Intel Pentium 4 or above/1GB RAM/80 GB Hard Disk 3.3.FUNCTIONAL SPECIFICATION The functional specifications for the functional blocks are provided by Fieldbus Foundation Organization.The Fieldbus Foundation is a global not-for-profit corporation consisting of leading process end users and automation companies. The functional specification of the function blocks which I developed are as follows. 3.3.1 Output Splitter Block The output splitter block provides the capability to drive two control outputs from a single input. Each output is a linear function of someportion of the input. Back calculation support is provided using the same linear function in reverse. Cascade initialization is supported by adecision table for combinations of input and output conditions.
10

This block would normally be used in split ranging or sequencing of multiple valve applications. A typical split range application has bothvalves closed when the splitter input is 50%. One valve opens fully as the input drops to 0%. The other valve opens as the input rises above50%. A typical sequencing application has both valves closed at 0% input. One valve opens fully as the input rises to 50%, and the otherstays shut. The second valve opens as the input rises above 50%, and the first valve may remain open or shut off quickly. Because this block is in the control path, it is able to pass limit and cascade initialization information back to the upstream block. Fig 3.3.1.1 shows output splitter block.

Fig 3.3.1.1 Output Splitter

The relationship of each output to the input may be defined by a line. Each line may be defined by its endpoints. Examples of graphicalrepresentations of OUT_1 and OUT_2 vs. SP are shown below in figure 3.3.1.2 for a split range and a sequencing application.

11

Fig 3.3.1.2Graphical Representations of OUT_1 and OUT_2 vs. SP

There is no limiting applied to the SP. The SP may be used in Auto modefor testing. The operator would use the output of the PID to accomplish the same purpose. Each downstream block can be taken out ofcascade if it becomes necessary to gain control of them. The examples shown do not show the full range of possibilities. The lines could overlap like an X, or both start from the origin but havedifferent slopes. The endpoints do not have to lie within 0-100%. Limits in the external blocks may affect the useful range of a line. Unitsof percent are used in the examples because the common application of this block is to valves, but any units may be used to suit theapplication. The following parameters may be used to specify the output splitter operation: X11, Y11, X12, Y12 X21, Y21, X22, Y22 Where Xnj is the value of SP associated with OUT_n and Xn1 and Xn2 refer to the 1st and 2nd coordinates of the nth curve respectively. Ynjis the value of OUT_n and Yn1 and Yn2 refer to the 1st and 2nd coordinates of the nth curve respectively.

12

Fig 3.3.1.3 IN_ARRAY & OUT_ARRAY

By specifying the coordinates as shown in figure 3.3.1.3, the endpoints of the lines are defined. Thecontents of the respective Xs are held in theIN_ARRAY parameter and the contents of the respective Ys are held in the OUT_ARRAY parameter. If a set of points are specified suchthat a region of the input range is not specified, then the corresponding OUT_n may be set to the closest endpoint of the input value, eitherhigh or low, when the specified region is exceeded.A configuration error shall be set in BLOCK_ERR and the actual mode of the block shall go to Out of Service if the X values have any ofthe following conditions: X21 < X11, X12 <= X11, X22 <= X21. The parameter LOCKVAL provides an option to specify whether OUT_1 remains at its ending level when control is switched to OUT_2,or goes to Y11. If LOCKVAL is true, OUT_1 remains at its ending value when X is greater than X12. If LOCKVAL is false, then OUT_1goes to Y11 when X is greater than X12 . Some hysteresis in the switching point may be required because the output may change by a fullstroke of the valve. HYSTVAL contains the amount of hysteresis. If X <= X12-HYSTVAL, OUT_1 may be determined by the calculatedy value. If X12-HYSTVAL < X < X12 and X has not reached X12 since it was less than X12-HYSTVAL, OUT_1 may be determined bythe calculated y value. If X12HYSTVAL < X < X12 and X has reached X12 since it was less than X12 -HYSTVAL,

13

OUT_1 may bedetermined by the LOCKVAL setting. If X12 < X, OUT_1 may be determined by the LOCKVAL setting. In the figure 3.3.1.4 LOCKVAL = true:

Fig 3.3.1.4 OUT with LOCKVAL True

In figure 3.3.1.5 LOCKVAL = false:

Fig 3.3.1.5 OUT with LOCKVAL False

14

Consider the configuration in figure 3.3.1.6

Fig 3.3.1.6 OUTPUT SPLITTER Configuration Where:PID1 = Upstream driving controller, Splitter = Split range function block being described, AO = Receiver of OUT_1 for 0-50% range of SP, PID2 = Receiver of OUT_2 for 50-100% range of SP CAS_IN of the Splitter receives the OUT of PID1. BKCAL_IN of PID1 receives BKCAL_OUT of the Splitter. CAS_IN of the AOreceives OUT_1 of the Splitter and PID2 receives OUT_2 of the Splitter. BKCAL_IN_1 of the Splitter receives BKCAL_OUT of the AOand BKCAL_IN_2 of the Splitter receives BKCAL_OUT of PID2. The splitter requires special handling for cascade initialization because it has two independent outputs. When a downstream block indicatesto the splitter that it wants to initialize, by asserting IR (initialization request) on its BKCAL_OUT, one of two things shall happen. Undersome circumstances, it is possible to pass an initialization request from a downstream block back up to the block upstream of the splitter,so that all three blocks balance for bumpless transfer to cascade mode. Otherwise, the requested splitter output shall go to the requestedvalue by placing an internal offset between that output and the output of the curve, and then ramping that offset to zero in BAL_TIMEseconds after the cascade is made up.

15

The splitter normally runs with both outputs connected to blocks in cascade mode. If one or both of the blocks is not in cascade mode,special limiting action shall be taken. Specifically, if one block indicates that it is not in cascade by NI (not invited) status on itsBKCAL_OUT, then the BKCAL_OUT of the splitter shall assert limits at the range extremes of the block that is still in cascade mode.Even if the upstream controller does not want to operate in that range, there should be no reset windup when it can move into the range. Ifboth downstream blocks show NI, then the splitter can only wait until one of them requests cascade initialization. BKCAL_OUT of thesplitter can hold the upstream block at the value of the SP. The actual mode shall be IMan. When cascade initialization is requested, by IR substatus on a BKCAL_IN, it is first necessary to determine if the other BKCAL_IN has NIsubstatus. If so, the value at the BKCAL_IN asserting IR is taken as the Y value for its curve, and the resulting X value is sent onBKCAL_OUT to PID1. If the other substatus is OK, then the internal offset and BAL_TIME shall be used. If both blocks have IRsubstatus, then one output shall be processed until its cascade is closed. The choice is based on the presence of limit status in BKCAL_IN.If BKCAL_IN_1 is limited, then if BKCAL_IN_2 is not limited then OUT_2 is processed first, else OUT_1 is processed first.Cascade initialization is also required when the block transitions from Auto to Cas mode. The BKCAL_OUT status shall show limited high if an increase in SP cannot be effectively passed on to either output because theBKCAL_IN_n of both outputs indicates that a move in the needed direction is limited. Similarly, limited low shall be set if a decrease inSP cannot be effectively passed on to either output. The slope of the limited line(s) affects the limit direction. BKCAL_OUT shall alsoshow limit status at the X extremes X11 and X22.

16

Sub-status values received at CAS_IN shall be passed to both outputs, except for those used in the cascade handshake. IFS shall go toboth outputs. The status option IFS if Bad CAS_IN is available. If the status Option to Propagate Fault Backward is selected in the output blocks downstream of the splitter block, then the splitter blockshall propagate the BKCAL_IN status of Bad, Device failure or Good Cascade, Fault State Active or Local Override only if the status ofboth BKCAL_INs contain a propagated fault status. MODES SUPPORTED:OOS, IMAN, AUTO & CAS

3.3.2 Multiple Discrete Input Block The MDI block makes available for the FF network eight discrete variables of the I/O subsystem through its eight output parametersOUT_D1/8. Fig 3.3.2.1 show multiple discrete input block.

Fig 3.3.2.1 Multiple Discrete Input

The multiple discrete input (MDI) function block processes multiple discrete input from field device and makes them available to other function blocks at its output (OUT_D1/8). Channel number is used to select the measurement value. Figure above illustrates the primary inputs and outputs of the MDI function block.
17

The MDI block supports standard block alarms, status calculation, and mode control. In Automatic mode, blocks each output parameter (OUT_Dx) shows value and status. In Manual mode, OUT_Dx may be set manually. The Manual mode is reflected on the output status. When setting up the MDI block, channel must be set to a valid value. This ensures that the block leaves OOS mode and goes to assigned target mode. Under normal conditions, a Good: Non-Cascade status is passed through to OUT_Dx. Status indication in the OUT_Dx output parameters depends on the I/O subsystem and the transducer block, that is manufacturer specific. The block also supports the Status Action on Failure and BLOCK_ERR indications. When the block is set to Manual mode, OUT_Dx is set to Good: Noncascade, Constant status. Status indication in the OUT_Dx output parameters depends on the I/O subsystem and the transducer block, that is manufacturer specific.For example, if there is individual detection of sensor failure, it can be indicated in the status of related OUT_Dx parameter. Problem in theinterface to the I/O subsystem can be indicated in the status of all OUT_Dx as BAD Device Failure. A block alarm will be generated whenever the BLOCK_ERR has an error bit set. SUPPORTED MODES: OOS, MAN & AUTO

3.3.3 Multiple Analog Input Block The MAI block makes available for the FF network eight analog variables of the I/O subsystem through its eight output parameters OUT_1/8, whose values must be expressed in engineering units. Fig 3.3.3.1 shows multiple analog input block.

18

Fig 3.3.3.1 Multiple Analog Input

The multiple analog input (MAI) function block processes multiple analog input from field device and makes them available to other function blocks at its output (OUT_1/8). Channel number is used to select the measurement value. Figure above illustrates the primary inputs and outputs of the MAI function block. The MAI block supports standard block alarms, status calculation, and mode control. In Automatic mode, blocks each output parameter (OUT_x) shows value and status. In Manual mode, OUT_x may be set manually. The Manual mode is reflected on the output status. When setting up the MAI block, channel must be set to a valid value. This ensures that the block leaves OOS mode and goes to assigned target mode. Under normal conditions, a Good: Non-Cascade status is passed through to OUT_x. Status indication in the OUT_x output parameters depends on the I/O subsystem and the transducer block, that is manufacturer specific. The block also supports the Status Action on Failure and BLOCK_ERR indications. When the block is set to Manual mode, OUT_x is set to Good: Noncascade, Constant status. Status indication in the OUT_x output parameters depends on the I/O subsystem and the transducer block, that is manufacturer specific.For example, if there is individual detection of
19

sensor failure, it can be indicated in the status of related OUT_x parameter. Problem in theinterface to the I/O subsystem can be indicated in the status of all OUT_x as BAD Device Failure. A block alarm will be generated whenever the BLOCK_ERR has an error bit set. SUPPORTED MODES: OOS, MAN & AUTO

3.3.4 Arithmetic Block The Arithmetic functional block is intended for use in calculating measurements by combinations of signals from sensors to give output for desired arithmetic function. Fig 3.3.4.1 show multiple analog output block.

Fig 3.3.4.1 Arithmetic

This block is designed to permit simple use of popular measurement math functions. The user does not have to know how to write equations. The math algorithm is selected by name, chosen by the user for the function to be done.

20

The following algorithms are available: 1. Flow compensation, linear. 2. Flow compensation, square root. 3. Flow compensation, approximate. 4. BTU flow. 5. Traditional Multiply Divide. 6. Average. 7. Traditional Summer. 8. Fourth order polynomial. 9. Fourth order polynomial based on PV 10. Simple HTG compensated level. Figure 3.3.4.2 gives a pictorial idea of the overall algorithm of Arithmetic block:

Fig 3.3.4.2 Schematic diagram of Arithmetic

IN and IN_LO inputs are dedicated to a range extension function that results in a PV, with status reflecting the input in use.The range extension function has a graduated transfer,

21

controlled by two constants referenced to IN. An internal value, g, is zero for IN less than RANGE_LO. It is one when IN is greater than Range_HI. It is interpolated from zero to one over the range of RANGE_LO to RANGE_HI. The equation for PV follows: PV = g * IN + (1 g) * IN_LO (3.1)

If the status of IN_LO is unusable and IN is usable and greater than RANGE_LO, then g should be set to one. If the status of IN is unusable, and IN_LO is usable and less than RANGE_HI, then g should be set to zero. In each case the PV should have a status of Good until the condition no longer applies. Otherwise, the status of IN_LO is used for PV if g is less than 0.5, while IN is used for g greater than or equal to 0.5. Block has 5 inputs: IN. IN_LO, IN_1, IN_2 and IN_3. Out of these 5 inputs three inputs IN_1, IN_2 and IN_3 are auxiliary inputs. These three inputs are combined with PV in a selection of fourth term math functions that have been found useful in a variety of measurements. Six constants are used for the three auxiliary inputs. Each has a BIAS_IN_i and a GAIN_IN_i. Here the bias is added and then sum is multiplied by gain. The result is an internal value called t_i in the function equations. The equation for each auxiliary input is the following: t_i = (IN_i + BIAS_IN_i) * GAIN_IN_i The ten different mathematical algorithms are defined as follows: 1. Flow compensation, linear. Used for density compensation of volume flow. func = f * PV f = t_1 / t_2 [limited] (3.3) (3.4) (3.2)

22

2. Flow compensation, square root. Usually, IN_1 is pressure, IN_2 temperature, and IN_3 is the compressibility factor Z. func = f * PV f = sqrt (t_1 / t_2 / t_3) [limited] (3.5) (3.6) the

3. Flow compensation approximate. Both IN_2 and IN_3 would be connected to same temperature. func = f * PV f = sqrt (t_1 * t_2 * t_3 * t_3) [limited] (3.7) (3.8)

4. BTU flow, where IN_1 is inlet temperature, and IN_2 the outlet temperature. func = f * PV f = (t_1 - t_2) [limited] 5. Traditional Multiply Divide. func = f * PV f = (t_1 / t_2) + t_3 [limited] 6. Average. func = (PV + t_1 + t_2 + t_3) / f where, f = number of inputs used in computation (unusable inputs are not used). 7. Traditional Summer. func = PV + t_1 + t_2 + t_3 8. Fourth order polynomial. All inputs except IN_LO are linked together. (3.14) (3.13) (3.11) (3.12) (3.9) (3.10)

23

func = PV + t_1 ** 2 + t_2 ** 3 + t_3 ** 4 9. Fourth order polynomial based on PV

(3.15)

func = PV + GAIN_IN_1*(PV**2) + GAIN_IN_2*(PV**3) + GAIN_IN_3*(PV ** 4) (3.16)

10. Simple HTG compensated level, where PV is the tank base pressure, IN_1 is the top pressure, and IN_2 is the density tap. func = (PV -t_1) / (PV - t_2) (3.17) density correction pressure, and GAIN is the height of the

Difficulties with the function, such as division by zero and roots of negative numbers, should be handled gracefully: 1. Division by zero should produce a large number of the proper sign. Infinity cannot be used, as it has a special meaning for unused limits. So we can use COMP_HI_LIM. 2. Roots of negative numbers should produce the root of the absolute value, with a negative sign. After the value of func is calculated, it is multiplied by GAIN, and then BIAS is added to the result. Finally, high and low output limits are applied, and the result is the term PRE_OUT. If the mode is Auto, PRE_OUT becomes OUT. The algorithm shall never change the mode, even when inputs go bad. The output of the calculation function shall always be displayed in PRE_OUT. If the mode is Auto, PRE_OUT becomes OUT. SUPPORTED MODES: OOS, MAN & AUTO

24

3.3.5 Multiple Discrete Output Block The MULTIPLE DISCRETE OUTPUT (MDO) block makes available to the I/O subsystem its eight input parameters IN_D1/8. Fig 3.3.6.1 shows multiple discrete output block.

Fig 3.3.5.1 Multiple Discrete Output The Multiple Discrete Output (MDO) function block processes discrete input values and if any of the input is in fault state besides a delay time it holds preset values for each point. This function block keeps the fault state features specified for the DO block. It includes option to hold the last value or a preset value whenin Fault State, individual preset values for each point, besides a delay time to go into the Fault State. The actual mode will be LO only due to the resource block (SET_FSTATE parameter). If an input parameter has a bad status, thatparameter will be in Fault State, but the mode calculation of the block will not be affected.Standard transition is in and out of OOS. The parameter, FSTATE_STATUS, shows that points are in Fault State. The MDO block does not support back calculation, or the Cas mode. SUPPORTED MODES: OOS, LO & AUTO

25

3.3.6 Multiple Analog Output The MULTIPLE ANALOG OUTPUT (MAO) block makes available to the I/O subsystem its eight input parameters IN_1/8. Fig 3.3.6.1 shows multiple analog output block.

Fig 3.3.6.1 Multiple Analog Output

The Multiple Analog Output (MAO) function block processes analog input values and if any of the input is in fault state besides a delay time it holds preset values for each point. This function block keeps the fault state features specified for the AO block. It includes option to hold the last value or a preset value whenin Fault State, individual preset values for each point, besides a delay time to go into the Fault State. The actual mode will be LO only due to the resource block (SET_FSTATE parameter). If an input parameter has a bad status, thatparameter will be in Fault State, but the mode calculation of the block will not be affected. The FSTATE_STATUS parameter shows that points are in Fault State. The MAO block does not support back calculation, or the CAS mode. SUPPORTED MODES: OOS, LO & AUTO

26

CHAPTER 4 DESIGN PHASE

In Software Engineering a class diagram describes the structure of the system by showing its attributes and operations (or methods). Following are the class diagram of each block that I have developed: 4.1 OUTPUT SPLITTER BLOCK

Fig 4.1.1 Output Splitter Class

27

4.2 MULTIPLE DISCRETE INPUT BLOCK

Fig 4.2.1 MDI Class

28

4.3 MULTIPLE ANALOG INPUT BLOCK

Fig 4.3.1 MAI Class

29

4.4 ARITHMETIC BLOCK

Fig 4.4.1 Arithmetic Class

30

4.5 MULTIPLE DISCRETE OUTPUT BLOCK

Fig 4.5.1 MDO Class

31

4.6 MULTIPLE ANALOG OUTPUT BLOCK

Fig 4.6.1 MAO Class

32

CHAPTE PLE E TAT

Fi 5.1SIMFFD Impl ment ti n

33

As you can see in the Fig 5.1 the order of execution is FIM LINK CM. First the FIM is loaded which in turn activates the LINK. After that the Control Module (CM) which we want to execute is loaded. Field Interface Module (FIM) as the name implies is an interface module between the field, where devices are located, and the Human Machine Interface (HMI) where we control and analyze the working of the system. These FIM have links on which the controllers and the devices are connected. A Control Module (CM) contains the strategy which is combination of different functional blocks. The strategies are logics made according to the task we want to perform. Figure 5.2 shows how combination of functional blocks makes a strategy:

Fig 5.2 A Strategy

34

The functional blocks that are part of a strategy is taken from the devices attached to the same LINK on which the CM of that strategy is present. It is very important for correct execution that devices and the CM using functional from those devices are present on the same link. A device contains different functional blocks. The selection of functional blocks present inside a device is totally up to the manufacturer of that device. So any functional blocks can be combined to manufacture a device. But it is always logical to select those functional blocks whose combination may fulfill a purpose. Now when a CM is loaded, initialization of the all the functional blocks occur. Initialization happens only once during the execution cycle. After the CM is loaded execution of functional blocks start. The execution of functional block is periodic and happens after a fix period of time specified during configuration of CM. Figure 5.3 shows the Execution period of a CM.

Fig 5.3 Execution Period in CM

35

The execution time may be broken into three steps: 1. Pre-processing - snap of parameter values. 2. Execution - Function block outputs are determined. 3. Post-processing - Block output values, alarm and associated trend parameters are updated. This is shown in figure 5.4. It is important that the input parameter values used in a function block not change during execution. Also, the outputs it provides to otherfunction blocks must be time coincident. To support this, a copy of the input parameters will be captured, or snapped, at the beginning ofexecution and the block output values will be updated only at the completion of function block execution.

Fig 5.4Steps of Execution Time

When the execution of a functional block starts first the GetVar() and StoreVar() functions of the corresponding functional block class (mentioned in the class diagram) are executed to fetch the values required by the blocks variable. After this the values of the parameters are fixed for the execution of the algorithm for that particular time. Since the blocks are executed

36

periodically, if the value of any parameter changes it will be reflected in the next execution of that functional block. Now the block algorithm execution will start. Once the values are fetched to the block they need to be validated, so a write_handler() function is called. This function validates only those variablesfor which the value is fetched. For Eg: If we have a boolean variable then we need to validate that the value fetched is either 0 or 1. Similarly if a variable is supposed to take values from 1-9 then we make sure that no other valuable is acceptable out of this range. If the value entered is not acceptable an error message should be displayed. Once the values are validated we can execute the algorithm further for that functional block. Now we check for the mode in which the block will be executing.All blocks have a mode parameter, which determines the source of the data to be used for the block. All blocks must permit the Out of Service (OOS) mode. To be useful, a block must support at least one other mode. The permitted modes apply to the target mode. A write request to the target mode will be rejected if it does not match the permitted list. Aconfiguration device must not allow a mode to be permitted that is not supported. The actual mode is not constrained by the permittedmode, because some modes are required for initialization. Different types of modes are: 1. Out of Service (OOS) This mode stops the execution of the block. When the mode is changed to any other mode it will resume the execution of the block according to the algorithm. 2. Local Override (LO) This mode is set when there is fault in the hardware of the system.

37

3. Initialization Manual (IMAN) This mode is set when the target mode is not reachable because of some block configuration error. 4. Manual (MAN) This mode is set when the user wants to give the output directly to the next block. This mode is chosen mostly when we want to give certain value as input for processing to the next block. 5. Automatic (AUTO) In this mode the algorithm is executed as intended, without any error or interruption by the user. 6. Cascade (CAS) This mode is used when the block is dependent on the status of outputs of other blocks to which it is connected. After this step the input parameter are processed according to the functionality of that block and then we get the output of that block. After the execution of algorithm there is post-processing of functional block in which the output value with its status is made available to the next block. Along with this alarm parameters are also activated if needed. For Eg: If we set the limit of output 100 as HI or 200 is HI_HI then corresponding alarm will be set in the block. Figure 5.5 shows different alarms and it properties.

Fig 5.5 Alarms Following figure 5.6 shows the flow of execution of common functions in a functional block.
38

Fi 5. Fl w of Execution

39

CHAPTER 6 TESTING

The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or weakness in a work product. It provides a way to check the functionality of components, sub assemblies, assemblies and/or a finished product. It is the process of exercising the code developed with the intent of ensuring that it meets the requirements and user expectations and does not fail in an unacceptable manner.

6.1 UNIT TESTING Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program inputs that produce valid outputs. All decision branches and internal code flow should be validated. It is the testing of individual software units of the application. It is done after the completion of an individual unit before integration. This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component level and test a specific business process, application, and/or system configuration. Unit tests ensure that each unique path of a business process performs accurately to the documented specifications and contains clearly defined inputs and expected results.

40

6.2 TEST CASES Following figures show the test cases of functional blocks developed: 6.2.1 Output Splitter Block

Fig 6.2.1.1 Output Splitter Test Cases (i)

Fig 6.2.1.2 Output Splitter Test Cases (ii)

41

Fig 6.2.1.3 Output Splitter Test Cases (iii)

6.2.2 Multiple Discrete Input Block

Fig 6.2.2.1 MDI Test Cases

6.2.3 Multiple Analog Input Block

Fig 6.2.3.1 MAI Test Cases

42

6.2.4 Arithmetic Block

Fig 6.2.4.1 Arithmetic Test Cases (i)

Fig 6.2.4.2 Arithmetic Test Cases (ii)

43

Fig 6.2.4.3 Arithmetic Test Cases (iii)

6.2.5 Multiple Discrete Output Block

Fig 6.2.5.1 MDO Test Cases

44

6.2.6 Multiple Analog Output Block

Fig 6.2.6.1 MAO Test Cases

45

CHAPTER 7 FUTURE SCOPE OF PROJECT

This project is currently developing independent functional blocks in simulation environment for foundation fieldbus devices. This development in future can be used for designing and developing in real environment.

We can try and make it more time efficient in future by able to do fast installation of foundation fieldbus devices as compare to now.It means we should be able to do the testing and then directly port to the real time environment. We know the fact that error reduction by this is nearly 99%. In future we can try and eliminate every possibility of error and make it 100% error free, thus making it more reliable than ever.

As per the market there is huge market for operator training. Currently the company itself provides operator to the customer. In future we should be able to provide training separately.

One of the major enhancements that can be done is maintenance. As per foundation fieldbus devices are considered, they need very much maintenance which is one the major reason of using them in industry. But we need to provide better maintenance for the whole system. This is one the area which will be beneficial to operator.

46

CHAPTER 8 CONCLUSION

This project has created a way to simulate the entire process which will be used in real environment in future. The main advantage with this is that the systemis optimized. Not only this, but also the outputs hereare more accurate as the errors are reduced to almost nil (99%). It is economically more efficient and saves loads of time.

The building of the different functional blocks is carried out independently which helps vendors to combine these functional blocks as per the need of client. The transition from simulated environment to real environment is made very reliable and efficient.

The development of independent functional blocks is an iterative process. After each development the blocks are sent for reviews and testing. The blocks have to pass all the integration testing where it is combined with other blocks to check for error free execution. The blocks may be regularly sent to the developers in case of any errors.

The only question which needs to be asked is with regard to maintenance of the systemin the real environment which is a very challenging task.

47

CHAPTER 9 BIBLIOGRAPHY ANDREFERENCES

1. VanisriSathyanarayanandSachinPargi, simulation of field devices, functional specifications, version 1.1, Honeywell Technology Solutions Lab.

2. Shashi Kumar M. Kolavi and Vanisri Sathyanarayan, simulation of field devices, Software maintenance document, version 1.3, Honeywell Technology Solutions Lab.

3. Ratnakar Nawathe, Plant Interface, functional specification, version 0.1,Honeywell Technology Solutions Lab.

4. Angela Summers, The Evolution of Plant Automation, Control Global, SIS-TECH Solutions.

48