The IEC 61158 fieldbus standard

The Physical Layer of IEC 61158 (IEC 61158-2) has been an international standard for some years now, and is widely used (by Foundation Fieldbus (FF), WorldFIP and Profibus PA). The other layers of IEC 61158 were narrowly rejected by an international vote last year, and instead were published as a Technical Specification (IEC TS 61158), not an international standard. However, the IEC Committee of Action has recognised the strong feeling among participants that this work should not be wasted, and has asked the Working Group to try again. The approach taken has been to allow other protocols to be included as "profiles", rather like the existing multi-protocol European standard EN50170.

Unfortunately, this has resulted in eight incompatible profiles being put forward: the existing TS 61158 proposal (of which FF is a subset, and which is virtually identical with the ISA SP50 Fieldbus specification, due to become a USA ANSI standard), ControlNet, Profibus, P-Net, FF's High-speed Ethernet, Swiftnet, WorldFIP and Interbus! This doesn't seem to be what the Committee of Action had expected, and is surely not what the international users want. (The insistence of users, that a single protocol was important, has been one of the major factors delaying past fieldbus standardisation efforts.)

Voting for this set of incompatible protocols is now under way, with a closing date in mid-December. National committees have to vote all or nothing - there is no option to accept some but not all of the protocols on offer.

My own opinion is that such a multi-headed standard is no standard, and is not worth having. Suppliers seem to be supporting it - maybe it's the only way forward - but what about users?

Earlier support for the original IEC 61158 (now the TS) proposal came from many international suppliers, including, for example, Foxboro (WayBack Machine Archive).

A Fieldbus debate at ISA TECH/1999 in October is reported in the online edition of InTech (WayBack Machine Archive).

A contrary opinion comes from Profibus (WayBack Machine Archive).

As I understand it, if this proposal is rejected, the original 61158 (TS) will automatically go forward from its present status as a Technical Specification to become a full IEC Standard. I believe that would be far the best outcome. If you care about this, please make the effort to contact your national committee and tell them your views.

And let me hear your opinions - I'll add them here. Here are some I have received already ...

The following is the text of an expert Brazilian evaluation for their National Committee:

****************************************************************
Brazilian Manifest ref. IEC Fieldbus Votes on 15. Dec. 1999
****************************************************************

Brazil is in favor of a future oriented Fieldbus Basic Document which allows to build several different application-specific devices which can communicate on a common single Bus/Network, as is the case with IEC TS 61158.

The Documents in question 65C / 223-224-225-226 / FDIS only select and shuffle eight of many today existing solutions together in a enormous document and freeze all today existing incompatibilities. This last minute turnaround affronts the big effort done in many ISA/IEC meetings and inverts the initial purpose set by IEC, to find a common solution.

In favor of TS 61158, we have to reject the Multi-type 65C / 223 ... 226 / FDIS
************************************************************

Are the promoters of this Multi-type document aware of the confusion their solution will create by the users where several application-specific protocol types came together? Think of a hybrid boiler which can be heated with oil and electricity. To know the water temperature, have we to select an oil-type, lighting-type or a water-type temperature sensor? If we later on will heat with gas, need we to change it to a gas-type sensor? Are the producers and distributors in 5 or 10 years enough organized to attend a request for spare-parts, if they need to know type, subtype and protocol version numbers?

The very increased possibilities for mis-configurations will also increase the probability of fieldbus failure induced risks to equipment, plant and possibly human life. Are the promoters of the Multi-type solution ready to assume their part of responsibility in a catastrophic case? The world need the IEC TS61158 solution [in order] to do a reliable safety and risk analysis. Perhaps insurance-companies should also be involved in these questions.

Fieldbus is not a computer-game. Fieldbus controls the real world. A Fieldbus failure can provoke a disaster. The December 15th decision is too serious as that we can leave it to a "historic co-operation" of some "key fieldbus players".

Dear IEC, please show your technical leadership, giving all Engineers around the world a common base to build safe, clean and sustainable industrial plants and do not absorb their energy with a lot of particular, small and subtle differences in Multi-type protocols.

Sao Paulo 30.11.1999
Brazilian National Committee for Fieldbus
Lucia Franco <lfranco@iee.efei.br> (Chair of BrNC)

PS: This document is not copyright protected, feel free to send it to others interested in this matter. You can also support it and send to your national IEC committee.

The following discussion comes from Patrice Noury, a well-respected member of fieldbus working groups from France:

1 What is a standard:

In the IEC perspective this is the result of a consensus worked out by experts with the aim either to deal with safety of goods and people or more open business in removing trade barriers. This second objective can be achieved at several levels:

common vocabulary to express the features and performances in a comparable way

common specification to permit compatibility between devices (hardware/software)

common specification to permit interoperability between co-operating devices

A third perspective of standard is also to stabilise and put in writing the "state of the art". This last topic is still subject to discussion and conflicts.

So a standard results from a consensus of the member countries and it should be unique to achieve the above mentioned goals.

2 What is the relation between multi-solution standards and free trade:

As anticipated by solution sponsors, it permits each consortium to be recognised and to use freely their solution. Would it work this way? Who will choose the applicable solution in a given business.

First case: the country. According to IEC rules, an IEC standard is not directly published by each member country. It is transformed into a country standard. What is inside the country standard should be conformant to the IEC standard, but it can be a subset. This means that some countries may decide to select only certain types!

Second case: the user (or the process engineering company). As each solution is a standard, a user may request vendors to support the type he has defined which may not be the vendor choice. As no vendor can afford to support the 8 types, this means a preliminary arbitrary vendor selection!

Third Case: the vendor. If the user is not allowed to select the type he likes, then the various vendors will select their preferred type. Then the system that ties all the equipment will look awkward as a bunch of gateways interlinked together (with other protocols!). Then cost and performance will be out of control!

3 Expert ethic:

Experts in the IEC standardisation committees are supposed to represent only themselves and to perform the best of the state of the art for the benefit of all entities involved into a given technical problem. That was the behaviour that has conducted to the former IEC TS 61158, this is no longer the case with the current FDIS 61158. Experts and their organisations should voice their opposition to a proposition that neglect their efforts and will build jurisprudence for other standards. Why do we need to develop a consensus when standards can just be a collection of the dominant vendor solutions. Going this way means no standard in a very short time.

4 Long lasting of standards:

Standards take long to establish (may be too long), this is why they should be stable over years (ex: 4-20 mA), recognising in a multi-solutions standard, protocols that are nearly obsolete (because new development are going on) is counter productive. An IEC standard is, by definition, there for the mid term future. Are all the solutions proposed future proof?

5 Profiles:

IEC 61158 is supposed to provide a generic solution. A WG of SC65C which just met is in charge to define the profiles of it. When created, the objective was to limit the number of profiles to a handful principally driven by application domains (speed, safety, availability, type of field equipment...). Now with the new orientations it will become a set of families of profiles ending with a total of profiles above 20/30. So good luck to implementers of communication interfaces.

Patrice Noury

And finally, a little light relief from Switzerland:

In a remote hospital in a far country, the doctors were concerned with patients dying because of drug confusion.

The hospital board decided that all dangerous medicines would be labelled green, green being the color of venom.

A major German chemical laboratory objected that green meant safe and that all its dangerous drugs have always been labelled red, meaning danger.

A French laboratory refused the convention since it was using yellow, a violent color, as a natural choice and proposed green/yellow. The Germans suggested blue/white/red instead, which the French bluntly refused for obscure reasons.

The Laboratories of America came with several lawyers to impose blue labels, blue being the color of Prussic acid, a well-known poison.

Several meetings, many high ranking dinners in remote places and 10 years of negotiations were needed to settle the color, until the the board came up with a consensus unanimously approved and published emphatically, that any color, including white and black (which are the colors of death), would mean danger.

Since then, patients' intoxication keeps on, and the hospital staff only know one thing for sure: that there is no reliance on labels any more.

Home Top of page Consultancy