Project Work

[EngineerUmair]

Hi,

I am the student of M.S. Systems Engineering and recently started working on a project titled as

"Field Controller for Distributed Control System". In a first portion I am in a study phase as to what basically I have to searched for, and gathering material available on net and literature.



As a first assignment I have to come up with some calculations regarding the protocols that are being in used for communication between Field Controller and field devices for example sensors, valves etc.



I want to ask that can anyone please help me or guide me to compare different protocols as H1 in the case of FieldBus in terms of speed, data transfer rate, error correction, number of devices that can be connected let say for example data coming from 100 different sensors and the range that system can work efficiently for exmaple 100 meters or let say 1 Kilometer.

I would be thankful if someone can help me and suggests some sources of literature regarding this project.

Thanking you.
Umair Siddiqui

Umair Siddiqui

[flaviostz]

Check out this link:
http://www.process-controls.com/MTL/FieldbusWallChart.pdf
Regards,
Flávio

[Heather Santos]

Hello Umair,
FF has updated the System Engineering Guide and is available here:
http://www.fieldbus.org/index.php?option=com_content&task=view&id=150&Itemid=326
This will give you a better idea of the basics of an FF installation.

[Robin Burnikell]

Hi Umair,

Just to warn you, although Flavio put the effort into providing you the link to the MTL document (which was very useful at its time) that document's information is now very out of date. The document was printed in 1997 (see bottom right hand corner) and as an example much of the information relating to FF H1 is incorrect when compared to current specifications and practise, eg H2 was shelved, number of devices specified for H1 is not realistic, also no mention of HSE. Similar things apply to other buses it mentions.

In Flavios defense I cannot point you towards a more up to date document, but I would recomend you do not rely on the MTL document as so much has now changed.

Having said that I just thought of a leaflet we have which might be of use to you. The leaflet is on what to look for and how to compare control systems. Although written for FF and our System302 much of it is relevant for any modern control system, not just FF. You can find the document at http://www.smar.com/PDFs/Misc/20Q&A_ff_smar.pdf. Other info including that document is at http://www.smar.com/system302/index.asp

Hope this helps,

Robin

[EngineerUmair]

Hi
I am thankful for your positive reply corresponding to my project, but can you please tell me if I want to connect more than 100 field devices on H1 Foundation Fieldbus what shoul be the methodology and areas of concerns..
hope for your quick reply.
Umair Siddiqui


Check out this link:
http://www.process-controls.com/MTL/FieldbusWallChart.pdf
Regards,
Flávio

[EngineerUmair]

Hi
I am thankful for your positive reply corresponding to my project, and for the reservations that you expressed regarding Flavio's reply. Can you please add to my knowledge that if I want to connect more than 100 field devices on H1 Foundation Fieldbus what shoul be the methodology and areas of concerns..
hope for your quick reply.
Umair Siddiqui




Hi Umair,

Just to warn you, although Flavio put the effort into providing you the link to the MTL document (which was very useful at its time) that document's information is now very out of date. The document was printed in 1997 (see bottom right hand corner) and as an example much of the information relating to FF H1 is incorrect when compared to current specifications and practise, eg H2 was shelved, number of devices specified for H1 is not realistic, also no mention of HSE. Similar things apply to other buses it mentions.

In Flavios defense I cannot point you towards a more up to date document, but I would recomend you do not rely on the MTL document as so much has now changed.

Having said that I just thought of a leaflet we have which might be of use to you. The leaflet is on what to look for and how to compare control systems. Although written for FF and our System302 much of it is relevant for any modern control system, not just FF. You can find the document at http://www.smar.com/PDFs/Misc/20Q&A_ff_smar.pdf. Other info including that document is at http://www.smar.com/system302/index.asp

Hope this helps,

Robin

[EngineerUmair]

Hi
I am thankful for your help.
Umair Siddiqui


Hello Umair,
FF has updated the System Engineering Guide and is available here:
http://fieldbus.org/About/FoundationTech/Resources/
This will give you a better idea of the basics of an FF installation.

[Robin Burnikell]

Umair, I think you would find no one has implemented 100 devices, or anything like 100 devices on Foundation Fieldbus H1 or Profibus PA. As far as I know the limit is 32 devices (but someone could prove me wrong on that?). But even 32 is not a realistic number for most things other than a laboratory.

This an areas where I regret logical possibilities in a laboratory and normal practices vary hugely. It is also an area I am not going to be able to give you a full and detailed answer to via this message board as their are pages and pages and pages for you to read to understand it all, but in summary (as best I can)

Practically most system vendors recomend a limit of between 16 to 8 devices per bus segment (H1). As an example Smar typically recomends a maximum of 16 devices per bus. It is possible to have more devices (we have installed systems with more than 16), but many reasons make 16 devices or less a practical limit.

The main restricting factors (in my view) are;

1) Bandwidth
2) Power supply and distribution
3) Plant uptime - Commissioning, configuration, reliability etc

1) Bandwidth
Most device/instrumentation buses (including FF H1 and Profibus PA) are significantly restricted by the time available for communication on the bus (that is why we have higher level buses like FF HSE and Profibus FMS which are not significanty restricted in this way).

In simple terms the more devices per bus you have, the longer devices have to wait for their time to talk on the bus. This affects the macro-cycle and has a dirrect effect on the control time and the supervision time of the devices. So you will reach a point where if you have too many devices on a bus the bus becomes too slow for your requirements. Actual times achievable on the bus depends on too many things to mention here, but in sumary it is a combination of how good the suppliers system is and how good their devices are and what your configuration is.

2) Power supply and distribution
H1 and PA are able to provide both power and communications down the same pair of copper cores to the field devices. As a guess about 95% of H1 and PA field devices draw their power from the bus. The amount of power being consumed, the length of cabling and the wiring topology has specific constraints which must be adheared to see http://www.fieldbus.org/pdf/ag-140s.pdf Yet at the same time the physical layout of a plant defines the location of the devices. Wiring together the devices whilst remaining inside the contraints can often be more imposing than the bandwidth restriction. There are however many products on the market that can help to extend these constraints, but, normally at some point you will be contrained, especialy on a geographically big plant.

3) Plant uptime - Commissioning, configuration, reliability etc
Their is much interaction and joint dependancy between devices on a bus. Whether it be in their configuration, their power supply and distribution, their physical location in a plant, whatever, they are all dependant on the same bus. Again there are many products available to help protect some devices on the bus from some common problems but at the end of the day they are all on the same bus and there are often circumstances that can affect the whole bus. The more devices you have on a bus, the worse the impact it will have on you if you loose it.

Hope this helps,

Robin

[Heather Santos]

Hi Umair,

I think what you are after is 100 devices in a network, being able to communicate with eachother. Through the use of an HSE backbone network and HSE/H1 Linking devices, you can have an average of 12 devices per H1 segment, 4 segments on most Linking Devices, and 2 or 3 Linking Devices in the plant network.

Alternatively, with the use of HSE Field Devices, you could have all 100 devices on the HSE network. The FF specifications are inplace for developing an HSE device. However, we have not registered any to date.

[Robin Burnikell]

Hi Heather,

I must admit I wasn't thinking of that, I was still thinking about that wall chart that mentions 140 "Addressable" nodes per segment, and thought Umair might be thinking H1 could support as many devices per segment as some of the other buses. Glad you pointed out that Umair might be talking about the whole system not just one segment :-))

I'll keep quiet for a while before I dig an even bigger hole!

Sorry Umair if you were talking about a whole system not just one bus segment.

Robin

[EngineerUmair]

Hi Robin and Heather,

I am glad to have you people's quick response. Robin, thanks for the indication of different constraints which must be kept in mind for the field devices on particular segment of H1 Foundation Fieldbus. I think I was little bit confused and wasn't able to posed my question completely and now thankx to Heather that he pointed out that infact I want to ask for whole network not particular segment.
I have studied one of the pdf file relating to wiring and installation of FF-H1 provided by you people and it suggests a chart that elaborates the constraints on spurs length as number of devices are increased on particular segment one of the question raised in my mind is that it was written in the chart that a maximum of 32 devices per segment can be connected then correspondingly it suggests the spurs length but again there is a flexibility that whether 1 device/spur or 2 devices/spur, 3 devices/spur upto 4 devices/spur so is that mean that if we are planning to use 32 devices on particular segment of H1 that means 32 spurs(if we are implementing H1 in bus with spurs topology) and if 4 devices per spur are used (obviously that is just the worst case condition and is not practically feasible as indicated by Robin) but if someone do that so is that mean we are connenting 32*4 = 128 devices on one segment of H1? (As I grasp the information from that chart if we use such an arrangement then all of the devices will have spurs length of just within 1 meter).
Heather, as you mentioned that we can use different segments of H1 with 12 devices each( so that total devices on all H1 segments sum up to 100 or more) and all of the segments connected to HSE through Link Devices this is okay but what if? if I use repeaters (as mentioned in the pdf file) not only to increase the length and range of network but also to increase the number of devices. As it is writen in the pdf file that a maximum of 4 repeaters can be used on particular segment of H1 FF so it means if we are using Type A cable (1900 m) so we can extend the range upto around 9500m written in file but obviously then there will be the costs of 4 repeaters with 2 terminators each is involved with its own power supply equipment and many more things like Linking devices or Bridges. Are there some issues still needed to be addressed and which solution is feasible in terms of cost time and efficiency.

Robin, I think you tried to mentioned some other protocols or buses which works even faster is that so? I am stressing at Foundation Fieldbus (HSE and H1) for my project work because it looks to satisfy my needs if all the pros and cons are clear to me and as you people provide me the information. Okay but obviously we can't implement HSE on a field device level as its length is limited to 100 meter but it works faster( 1Mb/s--->some Gb/s range) and obviosly field devices may be spreaded far a part in field upto some kilometers and H1 allow us to realise that as one segment length may be 1900 meter if we use Type A cable but then it works in the range of just 32.25Kb/s.

Well I am thankful to take you people's precious time and waiting for your positive reply.
yours Sincerely
Umair Siddiqui

[flaviostz]

Guys, of course that document was not updated, however most of the information in that document is true. Depiste of some old terminologies, I believe that document gives you an idea of the available protocols and how they are.

This is only an start point and an idea, you really need firstly to "dig" the Foundation web site. There is a plenty of literature for free to get you started !!! :)

Of course, you have to check that document against other references. It is a research, isnt?

Flávio

[Robin Burnikell]

Hi Umair,

Sorry for the very long time you have had to wait for this response. Work has been very very busy for the last few weeks so I was not able to answer you.

However, now I have some time to be able to answer your questions. I don't know if during waiting for this response you have been reading further material and hence you have increased your knowledge on FF? If you have then some of what I say next you may already know.

I regret the issue of FF H1 wiring and device limits is complex the first time you start looking at it. And the pages and pages of published literature is not as helpful as seeing a live system.

So before I go further I don't know what country you live in but please feel free to contact a Smar office or agent in your country, see www.smar.com/contactus.asp (http://www.smar.com/contactus.asp) and explain that you are a student working on the subject of FF and ask if there is the possibility to come and see a working system. I recommend asking to talk to the training manager. I am sure they will be pleased to invite you to their training centre and perhaps even organise a customer visit so you can get a feel for a real working installation. We all started as students and most of the time people are happy to help you, so just ask. I am sure the same applies to the other FF suppliers as well.

In your last post you ask questions about the number of H1 devices per segment, per spur etc. All of these questions relate to FF H1 and therefore my previous post covers these questions. Although 32 devices are theoretically practical, the real number used as a guide at the very earliest stages of design is 8 devices per H1 segment, this is a safe starting point. You can have more than this and you will at times have less than this (as it depends on many factors). Consequently if you only have 8 H1 devices on a Segment you would at most have 8 spurs on the segment. However, if you connect multiple devices to a spur then you would have fewer spurs.

Just remember although the specifications say up to 32 H1 devices per segment, the practical number in early stages of design is normally 8.

So therefore (As Heather pointed out) if you have a plant with 100 devices and we assume an average of 8 devices per segment you will need 100/8 = 13 H1 segments.

We now need to look providing the 13 H1 segment you need for your system of 100 H1 devices. I regret the design considerations around multiple H1 segments in a system is more complex than that for an individual H1 segment, so I am only going to be able to touch on the subject here, but none the less I can give you the key pointers.

To do this we need to look at system architecture and understand the different types of FF control system available. Please see the second page of this pdf www.smar.com/PDFs/Catalogues/SYSTEMARCE.pdf (http://www.smar.com/PDFs/Catalogues/SYSTEMARCE.pdf). Zoom into the diagram to be able to see the elements of the system.

In this architecture you can see:

Top right - the PC's which are used as operator workstations and engineering workstations. These are all connected to a standard Ethernet TCP/IP network working at 10/100Mbps. However the protocol on the Ethernet network for a pure FF system is FF HSE.

Across the middle - "FF Linking Devices" (Smar DFI302s), see www.smar.com/products/dfi302.asp (http://www.smar.com/products/dfi302.asp). Note a linking device is very different to a PLC or DCS with a FF interface card. On a system architecture diagram such as this one, there is little difference if any between a system using FF linking devices and one using PLCs or DCSs with interface cards, but the difference becomes very obvious when designing the system to meet control time requirements, as we will see latter.

Bottom left - the process plant.

The red lines indicate H1 segments. Note the H1 segments originate from the Linking Devices.

As Heather said a typical FF linking device will support 4 H1 segments.

Therefore in your system of 100 devices where you need 13 H1 segments, you will need four Linking Devices (DFI302s). This will actually provide you with 16 H1 segments (4*4).

So now we need to look at the system design considerations for the Linking Devices.

Firstly the linking devices can sit on either a Copper (e.g. Cat5 10BaseT) or a Fibre optic (10BaseF) Ethernet network. Ethernet has its own wiring and topology specifications and restrictions, which in the final design stages of an actual system you would need to know. But essentially Ethernet is so flexible that in the early design stages you just put Ethernet where you want it and then select the right Ethernet components later. This is different to H1 where you must keep the restrictions of H1 in mind all the time.

Using Fibre Optics you can locate your linking devices and therefore your H1 Segments almost wherever you want (within the limits of any hazardous area restrictions that might apply).

So now we can see that on a typical FF system we would assume 8 devices per H1 segment, four segments per linking device (e.g. DFI302) and then connect the Linking Devices by Ethernet to each other and the control system PC's. On a pure FF system the protocol on the Ethernet would be FF HSE.

It sounds very simple and straightforward but I regret it isn't that simple. The problem is control is sometimes required between H1 devices on different H1 segments.

FF H1 is deterministic, when you design your H1 segment you know how long it will take that segments control strategy to respond to process changes. This is very important and differentiates control technologies such as H1 from Data exchange technologies such as TCP/IP.

When you set out to design a control system there are two very important pieces of information from the client:

1) What is the control time (response) required in the plant (typically 0.5-1 sec)

2) What is the supervision time (e.g. HMI refresh rate) required by the plant (typically 1-2 sec).

If you can keep all the H1 devices that interact on a particular control strategy, (e.g. three element control such as boiler water level) on a single H1 segment, and ensure ALL the control for the segment is made in the Field devices, then the control time is the macro-cycle time for that H1 Segment. You then have to ensure you have also provided enough time allowed in the Macro-cycle to enable the supervision times required. The macro-cycle and its affect on control-time and supervision, is another subject in its own right, but I will assume you are familiar with it?

So lets assume on your system of 100 H1 devices, you have not been able to keep all the H1 devices involved in individual control strategies on the same H1 segments, i.e. you need to implement control across two H1 segments.

The next best option is if both H1 segments are connected to the same linking device. The linking device can then internally use a Function Block(s) in each H1 segment to exchange and synchronise the control data that needs to pass between the H1 segments. Depending on the control strategy involved the control time could now be the two macro cycle times added together.

The worst case scenario is that the two H1 segments are on different linking devices. In this case your control strategy is then additionally reliant on the Ethernet communications (FF HSE) between the linking devices to implement the control. In any circumstance where control is required over Ethernet working out the control time is more complicated and I regret I don’t have time to explain it here.

So Umair, I hope this helps you design your system.

Regards,

Robin

[EngineerUmair]

Hi Robin,
I hope you are fine, well I can understand the way you people are helping the novice like me regarding the the fieldbus and give your precious time.
In your last mail you have pointed out some crucial design issues which definitely help me in uncerstanding the whole scenario.
I am infact from Pakistan and currenly doing my MS in Islamabad and the link that you have given that is www.smar.com/contactus.asp (http://www.smar.com/contactus.asp) contains a representative of SMAR in Karachi(which is my home city) so I hope after exams I may find time to visit them or correspond with them.
Anyway thanks for your kind help.
Yours Sincerely
Umair Siddiqui

[EngineerUmair]

Hi
Basically my ultimate goal is to design a field controller and for that it is necessary to understand the pros and cons of the fieldbus that I will going to use so can you tell me the specifications for the controller I should look for like data rate at which it will communicate or control the field devices, number of digital and analog input/outputs of controller etc( I want to ask what other issues or specs that I should look for). basically I want to have general information regarding the field controller.
Thanks
Umair Siddiqui

[Robin Burnikell]

Hi Umair,

The number of FF projects has grown significantly recently, so my apologies that once again I have not been able to answer sooner.

I regret I am not clear on what you mean by a "Field Controller". Do you mean a HSE level control device (e.g. a FF "Linking Device" like the DFI302, not to be confused with a PLC or DCS with a FF card as these are not FF linking devices) or do you mean a H1 level controller device?

I suspect you mean a Linking Device like the DFI302?

The FF specifications themselves are your best source for information on this; however, the specs are open source but only for a fee (or so I believe)! You have to become a member of the FF to get your hands on them. Recognising that as a student spending money on gaining specs is not a viable option for you, I suggest that maybe you look at devices similar to that you want to develop for ideas and information.

Designing a controller for a FF system is not as easy as it was for a PLC or DCS system. With DCS and PLC systems the needs for the controller were relatively clear and was driven by the maximum quantity of I/O the controller was to support. Knowing the amount of I/O you wanted to control and the speed at which you wanted the controller to complete its processing cycles would lead you too a memory and processor speed based on your previous experience and control language implementation. This is a simplified view of course.

FF on the other hand, provides for the "possibility" to have ALL control in the field devices, rather than the traditional PLC and DCS approach of putting it all in centralised controllers.

But it is very important to note the use of the word "Possibility". To have a FF H1 registered device or a FF registered Linking Device just means it must be able to communicate using the FF protocol, it doesn't mean it will have any process control function capabilities, these are all optional parts of the FF specification.

To see what I mean look at the capability files (the .cff file) for different manufacturers FF H1 devices. These are text files which are freely available from the FF website e.g. http://www.fieldbus.org/ProductsAndServices/RegisteredProducts/?m=18, and contain detailed information about what the devices are capable of.

You will see that H1 devices fall into three categories (in my opinion); 1) No support for in field control, 2) limited support for in field control, and 3) wide support for in field control. Therefore the type of H1 devices you foresee being used with your Field controller (Linking Device) has a strong impact on the design requirements of it.

1) H1 Devices with no support for in field control.
Many H1 device manufacturers provide no support for control in their field devices. I won't mention names here but look for yourself; you will be amazed at how many big name manufacturers just support AI or AO in their devices. These manufacturers obviously believe the control should NOT be distributed at field level but should be centred in PLCs and DCSs. So when designing a Field controller, if your client wants to work with these relatively basic instruments your field controller will need lots of function blocks, lots of memory, a fast CPU to process all the control functions and redundancy at every component level within the controller to ensure you don't loose the controller, or else everything in your process stops!

2) H1 Devices with limited support for in field control
Most H1 devices only support very limited in device control, typically these devices will support only few types of control function block such as PID, Input Selector and the Characteriser block, in total around 10 function blocks and 20 VCRs. These devices allow some control functions to be implemented in the field. But in an overall system many other control system aspects such as logic, timers, leag lag, cross limits, complex maths, recipe data (constants) etc are required. As these devices don't support all these function they will have to be put in a centralised controller. Therefore if your system uses these types of devices your controllers still needs to be very similar to that used with basic devices, it doesn't need quite as much memory but it still needs to support the majority of the process control.

3) H1 Devices with wide support for in field control.
If you want to move ALL your process control into your H1 devices (many people do as this provides maximum system reliability as you have removed the MTBF aspect of a central controller from the system), then each device needs to effectively be a process controller so that it can cope with whatever process control requirements you throw at it and also manage when intermixed with less intelligent H1 devices. Therefore these devices must support a very wide range of function blocks and lots of VCRs. I believe Smar still leads this field by some margin, for instance Smar devices typically support up to 20 function blocks from a library of 17 types with 44 VCRs, e.g. Alarm, Complex Arithmetics, Characterisers, Constant blocks, Density calcs, Input selectors, Integrators, Leag Lag, Output Signal Selectors, Advanced PID, Set Point Generators, Splitters, Timers and Logic Blocks. Not bad for a range of H1 devices that are over five years old!

So you can see that in a powerful FF system when using field devices genuinely designed for control in the field devices, the role of the traditional field controller has changed in to that of a communication gateway between the HSE level and the H1 level and other control system standards e.g. Modbus, TCP/IP protocols, RS485 devices etc.

I hope this gives you some ideas for your project and a new perspective on what is required in a modern FF system.

Regards,

Robin

[EngineerUmair]

Hi Robin

I hope you are fine. Thanks for your precious time and for helping me out and please don't feel sorry for the late reply, I understand how busy you people are and it is enough that atleast you people are helping.
In my last mail by "Field Controller" I actually mean a H1 level Controller but definitely my second question will be regarding the controller for the HSE level so thanks for that.
Infact the filed controller (H1 level) that I should implement in my project is to be FPGA based so that the over all design is reconfigurable and if it is required to expand the system in terms of the number of field devices and some more control functions then we can easily do it by slight modifications(although it may involve much expertise) I mean that the basic purpose of implementing the controller on FPGA is that we can dynamically reconfigure it. So, I would be thankful if you help me in this and if you can mail me some papers or tell me some sites where material regarding PID controller that are implemented on FPGAs is available.
Umair Siddiqui

[Robin Burnikell]

Hi Umair,

I regret when it comes to the inner workings of the silicon chips that reside on our products I am not able to help you, although I know a person that will be able to help. However, I do not want to post his email address on this board. Please send me an email and I will forward your email to him (and cc it to you) so you can talk to him about it and see if he can help you. My email address is RobinBurnikell@SmarUK.co.uk

Regards,

Robin

[marisg]

Umair,

You may find some useful information on www.relcominc.com (http://www.relcominc.com) in the Fieldbus Wiring Guide.

Regards
Maris