interbus system technology basics - steven engineering
TRANSCRIPT
First steps with
INTERBUS INTERBUS System Technology Basics
INTERBUS -
The Sensor/Actuator Bus
A complete system overview with which you can quickly and easily
find answers to your questions on the INTERBUS system. You willalso get the know-how required for a first general decision on thefieldbus topic and especially on INTERBUS.
Any questions, suggestions, help, etc. Send mail to: WebMaster
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
[Top] [Prev] [Next] [End]
Contents
1. Preface to the INTERBUS Club
2. INTERBUS at the Center of Automation
2.1 Introduction
2.2 INTERBUS and Standardization
3. INTERBUS Technology
3.0.1 Demands of Sensors/Actuators on a Bus System
3.0.2 A Comparison of Data Transmission Methods
3.0.3 INTERBUS, the Sensor/Actuator Bus
3.0.3.1 INTERBUS Topology
3.0.4 The INTERBUS Transmission Protocol
3.0.5 Technical Implementation of the Transmission Protocol
3.0.6 The User Interface
3.0.6.1 PMS Services
3.0.7 Practical Application of INTERBUS
3.0.8 Standardized Start up, Operation and Diagnostics with the INTERBUS Manager CMD
3.0.9 INTERBUS Loop
3.0.10 Standardized Networking with INTERBUS
3.0.11 Device Interoperation with Profiles
3.0.12 INTERBUS Products and Manufacturers
3.1 Open Architecture in the PLC World using INTERBUS
3.2 Open Control
3.2.1 INTERBUS with PC-based Control Technology
4. INTERBUS in Action
5. The Way to INTERBUS-compatible Devices
5.1 Test and Certification
5.2 The INTERBUS Club
5.2.1 Your Way to the INTERBUS Club
5.4 INTERBUS Club International
[Top] [Prev] [Next]
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
Copyright © 1997, INTERBUS Club All rights reserved.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
1. Preface to the INTERBUS Club
Serial field bus technology is increasingly meeting with international acceptance in all areas of industrialapplications, starting with the automotive industry through to process engineering, materials handling,logistics, shipping, food processing, paper and timber industries and so on. Every sector in which industrialcontrol technology is used is suited for this relatively new technology.
The INTERBUS Club has published this brochure in order to provide potential users and manufacturers ofINTERBUS-compatible devices with a technical overview of the functionality, efficiency, delimitations, andapplications of INTERBUS. In the opening section it deals with the trend within open automationtechnology, further explains the INTERBUS protocol, points out possible areas of application and gives tipson the implementation of the devices.
All in all, what we are presenting you, the technically interested user or manufacturer, is a comprehensivedocument that serves to assist you in your further steps toward INTERBUS.
2. INTERBUS at the Center of Automation
2.1 Introduction
In the entire field of modern automation technology, new ways of electrically equipping machines andplants are under development. The enormous competitive and cost pressure which weighs heavily on allareas of production and process enginee-ring, necessitates the exploitation of existing rationalizationpotentials. From this point of view, the conventional parallel wiring of sensors and actuators in a machine orsystem turns out to be inflexible and a serious cost and time factor. A remedy for this is the serialnetworking of the components on the lowest level of the automation hierarchy by means of so-called"fieldbus systems". This represents a great opportunity to reduce costs.
At the same time, the increasing globalization of the markets is making new demands on systems andmechanical engineers regarding the solutions in control technology. The world of automation technology isno longer homogenous but is in stead dominated by national or regional market leaders. Machine and plantconstructors operating internationally have to take these conditions into account. At the same time, beingcompetitive on the international market means that an automation solution must be standardized and ableto be used worldwide without major alterations. The result of this has been the demand for open modularcontrol architectures which can be accepted worldwide or, with slight modifications, adapted to nationalpreferences.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
Future automation systems will therefore be based on flexible control systems, the performance andfunction of which can be adapted to changing requirements without interrupting the system. Under thisaspect, changing the control system or the control system manufacturer should not affect the otherautomation components. One precondition for these open control architectures, which result inconsiderable cost savings over the complete lifetime of the machine or system, is standardization in allareas of control technology. This stand-ardization is already happening in many cases. In future,manufacturer-specific programming languages will be replaced by the international standard IEC 1131.Since the introduction of the PC, special hardware for programming devices has become a thing of thepast. These trends enable users to interchange and freely select their control system. In terms of controlhardware too, the standard industrial PC is coming to the fore and beginning to oust the inflexible,manufacturer-specific hardware platforms. Another precondition for a truly open automation system is astandardized connection between the different makes of control systems and the wide range of processperipheral equipment currently available on the market. The solution to this problem is the implementationof serial bus systems which, apart from offering all the above-mentioned advantages, can also effect astandardization of the link between control system and peripheral equipment.
To meet the future challenges of an seamless flow of information and the support of open and flexiblecontrol architectures in automation engineering already mentioned, bus systems in the field ofsensors/actuators must meet two essential requirements.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The bus system must provide the user with a universal solution for his automation task. For applications inopen control architectures, it must feature independence and neutrality towards major PLC suppliers.Today, most solutions available on the market fail to meet these two requirements.
The necessary neutrality of the PLC manufacturers, which ensures interchange- ability of the controltechnology while using the existing process peripheral equipment, is often lacking. Each systemrepresented on today’s market is only supported by one of the major PLC manufacturers. The GermanPROFIBUS fieldbus is supported by the PLC manufacturer Siemens, DeviceNet by Allen-Bradley and FIPby Telemecanique. The availability of the system and its efficiency depend on the PLC manufacturer’sinterest in an open solution and can therefore not be guaranteed for any length of time. With this kind of"controlled openness", many manufacturers are attempting to create new dependencies and reestablishcustomer ties, previously achieved with special operating systems, programming devices and languages.To emulate a seamless solution for automation tasks (from the PLC via remote peripheral equipment todiscrete sensors and actuators), many systems must rely on a variety of different partial solutions due to alack of technical capability. By marketing products under a single name, manufacturers attempt to conveythe impression of a "pseudo universality". In reality, however, users are suddenly confronted with two, threeor even four completely different systems in their plants. This becomes evident for example in the case ofPROFIBUS with the variants, "FMS", "DP", "DP+" and "PA", or, in the case of Allen-Bradley, with thenetwork structure, Data Highway, Control Net and Device Net. This multitude of variants increases timeand costs for training, maintenance, stockkeeping, tools etc. and does not exactly enhance reliability of theplants. Justification for this variety of systems is often sought in theoretical hierarchy boundaries. However,the actual reason for this assortment of fieldbuses, as is the case with PROFIBUS and DeviceNet, is thelack of suitability of the implemented transmission protocols for use in the field of sensors and actuators. Inorder to create a seamless applicable protocol, from the control level through to discrete sensors andactuators, the protocol must be designed with the very special requirements of the "critical" area of sensorand actuator technology in mind. In contrast to the range of networks dominated by PLC manufacturers,INTERBUS provides a neutral and seamless solution which has been optimized for this field of application.
In the following, we will introduce INTERBUS, a sensor/actuator bus system, which, owing to its technicalcharacteristics, is particularly suitable for use in the field of industrial sensors and actuators, and laid out forconsistent networking from the control level down to the last limit switch. INTERBUS is not sponsored byone major PLC manufacturer, but is supported by an independent network supplier as well as currentlymore than 700 device manufacturers with new technical developments and products. Thus, INTERBUScan be considered as the "NOVELNET" of industrial communications and is therefore an essentialcomponent for future open and flexible control architectures. The availability and reliability of INTERBUS,as well as its application stability, is documented by currently more than 1.5 million networked field devices.
2.2 INTERBUS and Standardization
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
In Germany, following the wishes of the users, the key functions of INTERBUS were standardized by theDKE (Deutsche Elektrotechnische Kommission: German Electrotechnical Commission for DIN and VDE).In 1993, the DIN E 19 258 series was published. This lays down the transmission protocols and servicesneeded for process data communication. The specifications for parameter data communication are alsogenerally available and were published in the DIN Report 46 (1995).
The DKE has submitted the DIN E 19 258 series to CENELEC for standardization on a European level.The Technical Committee in charge has received the specifications for standardization as prEN 50 254,with the title "High Efficiency Communication Subsystem for Small Data Packages". The vote on thisstandard will be taken by the fall 1997, in a single-phase procedure in the countries belonging to theCENELEC. EN 50 254 is identical to DIN E 19 258 and will supersede it after publishing. The followingfigure shows the identical document structure of DIN E 19 258 and EN 50 254.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
[Top] [Prev] [Next]
3. INTERBUS Technology
3.0.1 Demands of Sensors/Actuators on a Bus System
The demands made by automation equipment on a communication network change drastically in thehierarchical course of the functional levels of a plant or factory.
In particular, the area of industrial sensors/actuators forms a very specific and individual requirementprofile. However, due to the traditional method of viewing situations "top-down", hardly any fieldbussolutions have so far taken this into account.
The areas where control systems and computers are networked, and those of sensors and actuatorscannot be regarded as a homogenous field, as their demands on a communication network are completelydifferent. PLCs, NCs, robot controllers and computers etc., are networked to each other on the processlevel. The exchange of data and programs ranging from several Kbytes to Mbytes per device is demand orevent-driven. This data represents unique information, the transmission of which must be secured viaappropriate acknowledgement and repetition mechanisms of the network protocol. The data is usuallytransferred not only to a system situated on the next hierarchy level (host computer), but also betweendevices on the same level. This is the classic "peer to peer" communication found in all higher-levelhierarchies. In the field of sensors/actuators, however, two additional properties are required, which areirrelevant in all other areas of automation levels. First, the network should be capable of carrying outtime-constant scanning of process data. Second, the data is reduced so drastically per device that theefficiency of the network protocol suddenly plays a crucial part.
The sensor/actuator level with its devices is the direct interface between the actual physical process andthe control systems or process control computers. Owing to this definition, this area comprises very simpledevices such as limit switches and contactors, which are part of the traditional I/O level of PLCs, as well ascomplex devices such as drive controllers and operating devices. These "intelligent" devices increasinglyimplement the distribution of classic central PLC functions. A network for sensors/actuators must not onlybe suited to simple but also to complex devices. Therefore, when determining the demands made on thenetwork, it is absolutely crucial to take into consideration the demands of all components interoperatingwith these devices and not just a single device class, such as drive components or sensors. Only anintegral approach prevents the creation of such heterogeneous single networks within the field ofsensors/actuators and control engineering overall. This concept of a uniform network which is orientedtowards the demands of all devices is to be our continuing theme.
An analysis of the communication characteristics of the devices in the area of the sensors/actuators showsthat the data to be transmitted can be divided into two basic types: first, the I/O or process data andsecond, the messages or parameters. Both data types are fundamentally different, whereby anunderstanding of their differing demands on a communication system is the elementary basis for therealization of a seamless sensor/actuator network.
- Process Data (I/O Data)
Process data is characterized by its direct effect on the physical process. Switch states or drive signals forcontactors and valves, for example, are process data, but also setpoints and actual values of drive controlsystems. Process data per terminal device is not highly complex and usually comprises no more than a fewbits. Because of the concept of decentralization, endeavors have been made to gather data and make itaccessible to the network at the point of origin. This results in a very large number of network devices,which may well extend to several hundred, each representing only a minute set of information. This amountof information per device is continuously reduced. Only a short time ago, it was an average of 8 - 16 bits.However, these days, state-of-the-art technology permits efficient networking of single sensors with only 1or 2 bits of information, a fact which must be taken into account when selecting a system. Process datahas the character of cyclic information which must be continually updated via the network. Furthermore, inorder to realize automatic control tasks, it is necessary to have constant and calculable scanning intervalsfor setpoints and actual values. In this context, this is also referred to as the demand of a deterministic andtime-equidistant data transmission. Due to the small amount of information per network device, thereusually is no local data preprocessing in the area of process data. Therefore, the transmission times must
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
be directly oriented towards the process time constants. Taking the capability of modern control systemsinto account and the necessary machine cycle times, the updating of process data contained in a networkmust be carried out within a period of 1 - 5 ms. It is likely that this time requirement will move in thedirection of its lower limit in the foreseeable future.
Process data is usually uniquely identified by its address or the terminal device it represents. An additionaldescription of this data for transmission purposes is therefore not necessary. The mapping of this data tothe application program should be in the form of a continually updated process image.
- Parameters (Messages)
Parameters are used to adjust, monitor and program "intelligent" devices. In contrast to process data,parameter information has a non-cyclic character. That is to say, the information is only transmitted ondemand and is therefore nonrecurrent. Transmission of parameter information requires special securityand acknowledgement mechanisms. The complexity of a parameter block in the area of sensors/ actuatorsranges from 10 to 100 bytes for device parameterization up to several 100 Kbytes for program information.In comparison to the highly dynamic process data, the time requirements for the para-meter transmissioncan generally be regarded as uncritical. Depending on the type of device and extent of the network, therequirements range between a few 100 ms and several minutes. Because intelligent data sources canreceive and send a wide range of information, a para-meter block is not identified by its device addressalone. In fact, its transmission requires additional, descriptive information which is included with the aid ofso-called communication services.
The fundamental data types mentioned can be used on all sensor/actuator devices. Simple devices aregenerally only represented by process data; "intelligent" field devices, on the other hand, e.g. drives, supplyor require both data types. In this way a drive is initialized and parameterized via the parameterinformation, while, for example, the setpoint and actual value for frequency and rotational speed are typicalprocess data which put very high demands on the network dynamics to realize control and closed-loopcontrol functions. However, even in the area of "simple" devices, the trend toward parameterization canincreasingly be seen. Serial networking provides the opportunity to parameterize even a simple sensor viathe network and these possibilities will be used more and more in the future. In addition to the differentcommunication requirements of the process data and the parameter information mentioned, generalrequirements of a sensor/actuator network can be formulated. A decisive aspect when designing such abus system is that the operation of the system should be tailored to the knowledge level of the staff onhand in the application environment. Staff working with networks in the area of sensors/actuators are notgenerally EDP specialists. Therefore, the network installation and maintenance must be simple and easy tounderstand. Stochastic or priority-controlled access procedures require time-consuming performance andutilization analyses of the network to determine worst-case access times and must therefore be ruled outfor a sensor/actuator network. A clear master-slave structure ensures deterministic access times as well asthe simple planning and design of the network. It must also be possible to service the network without theneed for special tools and time-consuming training. The system must be equipped with suchcomprehensive diagnostic functions that even a service technician unfamiliar with the system is able todetect defective system parts. Defective components must be easy to replace without the need for anyfurther adjustments to the device. Manual adjustment of device addresses, necessary in many networkconcepts, represent a high error risk and must be avoided.
This area also demands a data transmission rate that is as low as possible. Only in this manner can theuse of simple transmission media be ensured, which means easy installation, and the achievement of highelectromagnetic compatibility. At first glance this requirement appears to contradict the demand for shorttransmission times. In order to fulfill both demands, the protocol of the sensor/ actuator bus must optimallyutilize the implemented transmission rate, i.e. display a high rate of efficiency. It is therefore of noadvantage when a network has a data transmission speed of, for example, 12 Mbits. It is not thetransmission speed which is decisive but the data throughput achieved during transmission; this is alsocalled protocol efficiency.
The demands made on the size of a network vary enormously depending on the application. The distancebetween the devices may be just a few meters within a machine or several hundred meters in the areas ofinstallation, materials handling and warehousing.
When devices from different manufacturers are to be operated in an open network, a simple and, aboveall, non-proprietary diagnostic tool in the form of a computer-aided user interface is of particularimportance.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
As already demonstrated, the demands made on the communication system by the two basic deviceclasses or data types of the sensor/actuator systems differ completely. On the one hand, I/O transfer isimperative in order to realize the real-time demands, while on the other, a message transmissionmechanism, enabling para-meterization of devices, is also desirable. However, these conflicting demandsmust not lead to a single application area being served by two different networks, one for real-time I/O datatransfer and one for parameterization of devices. This would mean that those devices requiring both datatypes, such as drives, would have to be equipped with two network interfaces, an entirely unacceptablesituation for the user.
3.0.2 A Comparison of Data Transmission Methods
What sort of transmission mechanism is optimally suited to a sensor/actuator network? To answer thisquestion, we must first compare two basic methods of message transmission.
The classic, message-oriented transmission method is based on a logical point-to-point connectionbetween two devices. In order to transmit cyclic process data, a central master prompts each sensor insuccession with a message to send its input data. The prompt is acknowledged each time by the responseof the sensor. Transmission of data to the actuators is carried out in the same manner. In this case, thecontrol system sends a message with output data to an actuator. The actuator, in turn, acknowledges thismessage with a response. In this procedure a complete transmission protocol is executed between thecentral master and a slave, whereby a message with no user data contents is always transmitted via thenetwork. Besides the actual user data, a transmission protocol or message frame must also transmit alarge amount of overhead data (address, command, data back-up etc.). The fact that, typically, very littleinformation per device is transmitted in the area of the sensors/actuators and that the protocol mechanismis very time consuming, means that transmission of cyclic process data is very inefficient. However, this isnot the case where the non-cyclic transmission of parameter information is concerned. In principle,non-cyclic transmission corresponds to the point-to-point structure of the communication procedure.Furthermore, the typically long parameter blocks mean that the protocol efficiency is considerablyincreased. The message-oriented transmission method is ideal for the transmission of complex, non-cyclicparameter blocks, but is not suited to the cyclic transmission of short process data.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The second basic transmission method is the so-called summation-frame protocol. This method combinesthe data of all sensors and actuators of a network into one message. This message is sent to all devicessimultaneously. The transmission overhead occurs only once. Combining the information of all networkeddevices into one message frame expands the useful data block considerably. The efficiency of this protocolincreases dynamically with the number of networked devices, which, as we know, is typically very high inthe area of the sensors/actuators. The summation-frame protocol is optimally suited to the transmission ofcyclic process data. However, adding complex parameter information to the frame message would lead toa considerable lengthening of the frame and slow down runtime performance for short process data. Inaddition, the non-cyclic character of the parameter data is incompatible with the cyclic procedure of thesummation-frame method. By principle, the summation-frame method guarantees the demand fordeterminable and fixed scan intervals and its high efficiency provides a combination of a low datatransmission rate and a high data throughput.
The following short example demonstrates the major differences in efficiency between the communicationprotocol and the summation-frame protocol with regard to process data transmission. This example isbased on a system with 32 networked devices, each of which represents 8 bit process data. A typicalmessage-oriented transmission method requires an overhead of up to 200 bits in order to update this 8 bitprocess data. This means that efficiency of the system is approx. 4 %. In other words, only 4 % of the totaltransmission is utilized for user data. In the case of the CAN protocol-based DeviceNet, this efficiency is 8% and for the IEC fieldbus 5 %. Compare this to the summation-frame protocol with a single, constantoverhead, and an efficiency of over 60 % can be achieved. That is to say, to ensure the same scan times,the transmission rate of the message-oriented method must be increased by more than the power of ten.This ultimately leads to a situation where, in order for this method to achieve anywhere near currentresponse time requirements, transmission rates of several Mbits must be used. These rates constitute thelimits of what can be implemented with a justifiable expenditure, if these have not already been exceeded.It also means that, with regard to future applications, a dead end has been reached. Ultimately, themessage-oriented method has no more solutions to offer, if the demands on network response timescontinue to increase and the trend towards decentralization continues, i.e. a network comprises more andmore devices with less and less information. This becomes painfully clear when networking single sensors.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
Today, modern semiconductor technologies enable cost-effective connection of even single sensors andactuators to bus systems. However, because of their protocol characteristics, it is not possible to makesuch a connection and retain the necessary data throughput with fieldbus solutions based on themessage-oriented procedure. Even an increase of the baud rate, which often is already too high at severalMbits, has no further effect. The "pure" sensor interface systems, which arose as an alternative, only coversmall areas of the automation solution due to distance and data quantity limitations. Today, in some casesa "marriage of convenience" between the message-based protocol and the sensor interface system ispromoted as as a compromise solution. However, the result is not a solution which satisfies the user’sdemands, but another variant in the fieldbus assortment. The summation-frame method, however, offersfull data throughput without system interruption, even for discrete devices.
This comparison of transmission methods shows that neither of the two methods really satisfies the centraldemand for a universal network for cyclic I/O data and non-cyclic parameter information. The solution tothis problem lies in a synthesis of the positive characteristics of both procedures, which is a feature of theINTERBUS system.
3.0.3 INTERBUS, the Sensor/Actuator Bus
INTERBUS not only complies with the universally accepted sensor/actuator profile, but also satisfiescustomer demands for a solution which is user-friendly, open and an acceptable technology for the future(protection of existing investment).
INTERBUS uses a master-slave access procedure, whereby the bus master simultaneously acts as theinterface to the higher-level control or bus system. The INTERBUS topology is a ring system, i.e., alldevices are actively connected to a closed-loop transmission path. On the main ring leading off from themaster, subring systems can be formed to structure the entire system. These connections are carried outusing special components called bus terminal modules. A subsystem can be of a local character, referredto as the local bus, which is typically used to create local I/O clusters within a switch cabinet. On the otherhand, it can also be a system which couples remote devices over long distances. A distinctive feature ofthe INTERBUS system in comparison to other ring systems is the fact that both the forward and return datalines are contained in one cable which runs through every single device. This produces the physicalappearance of a line or tree structure. A common form of the physical layer of the INTERBUS system isbased on the RS 485 standard. This is a differential voltage interface, which uses twisted-pair leads for thetransmission of the signals. Due to its ring structure and because it has to carry the logic ground,INTERBUS requires a five-wire cable between two devices. With a data transmission rate of 500 Kbits, adistance of 400 m between two devices is possible due to the RS 485 point-to-point transmission. Theintegrated repeater function in each device enables an overall extension of the INTERBUS system of up to13 km. For ease of operation, the number of INTERBUS devices is limited to a maximum of 512.
3.0.3.1 INTERBUS Topology
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The point-to-point structure of the INTERBUSsystem and its division into main and subringsystems is ideal for the implementation ofcompletely different physical transmissiontechnologies and, in particular, the future-orientedfiber optic technology. The bus system isequipped in such a way that any part of thesystem can be converted from copper technologyto fiber optic technology, to infrared datatransmission systems or any other media usingstandard converters available on the market.Similarly, fiber optic-capable devices can beimplemented to set up whole networks based onthis interference-immune and installation-friendlytechnology. There is no need for the expensiverepeater converters as required by multidropstructures. The ring structure gives the systemtwo decisive advantages. First, and in contrast toa line structure, the ring permits data to be sentand received simultaneously (full duplex). Secondthe system’s self-diagnostic feature can beconsiderably improved using a ring system. In thecase of bus-type systems (trunk line) withmultidrop device connection, all devices are quasipassively coupled to the bus. However, thepassiveness of the devices is limited to error-free
operation only, or to a disconnection of the device. If a fault in the bus interface of a node causes ashort-circuit in the bus line, or if the line is short-circuited at any other point outside the device, no furthercommunication is possible at all in such a system. If this type of fault occurs in bus-type systems, it is notpossible to detect the location of the fault using the automatic diagnostic functions of the network. A ringsystem with active device coupling on the other hand provides a segmentation of the entire complex intoelectrically independent subsystems by its very nature. Thus, in the case of the active failure of a device, ashort-circuit or the disconnection of a bus line, communication is only interrupted from the location of thefault onward. The network management functions of the bus enable localization of the fault, so that theservice technician knows immediately where repairs are needed. The same applies to sporadictransmission faults e.g., caused by electromagnetic interference sources or faulty cabling. In the linesystem, this also accidentally destroys any number of messages. In the case of such an undifferentiatedinterruption in transmission, it is not possible to localize the fault. This results in repeated, and often lengthyinterruptions in the operation. The active device coupling of the INTERBUS system, which monitors everysingle transmission path, enables unambiguous fault location even in this case. It is precisely this faultlocation feature which is crucial when it comes to minimizing system downtimes. However, before a systemstandstill occurs, INTERBUS allows preventive error locating by means of a statistical evaluation of thesystem’s transmission quality. This error frequency evaluation allows, for example, the early detection ofcomponent failures due to normal wear, and prevention of a production standstill. With these possibilitiesfor the complete analysis of error type and error location, the INTERBUS system assumes an outstandingposition among fieldbuses. As a result of a uniform start up and diag-nostic concept for all INTERBUSdevices - consisting of diagnostic functions on the INTERBUS devices, front panel diagnostics on thecontroller boards and an oper-ator interface based on that of the PC - system diagnostics becomespracticable for the user.
The fact that local subring systems can be set up in the INTERBUS network also permits a connection anddisconnection of devices without interference. The coupling elements between the bus segments can becontrolled by the central bus master and permit the subsystem to be enabled and disabled. It is thereforepossible to manipulate the subsystem without affecting the rest of the system in any way.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The data is not allocated to individual devices by assigning a bus address to individual devices, as isnecessary in other systems, but, due to the active device coupling, via the physical position of the devicewithin the ring system. This contributes considerably to the ease of maintenance of the system.Unfortunately the problems and errors which can occur when device addresses need to be set manuallyduring installation or maintenance are often underestimated. In addition to this automatic physicaladdressing of the bus devices, optional logical addressing of individual bus devices can be carried out at acentral point in the bus master by simply creating an address allocation list. This makes the deviceaddresses used by the application program independent of their physical position in the system. It alsoenables problem-free removal and addition of devices in the ring without the need to change existingaddress lists.
3.0.4 The INTERBUS Transmission Protocol
The INTERBUS protocol stack is struc-tured in three layers in compliance with the ISO/OSI model.
Layer 1 is the Physical Layer. It is here that the time conditions such as baud rate, permissible jitter and soon, as well as formats for cable coding are determined.
In layer 2, the Data Link Layer, the integrity of the data is guaranteed. The Data Link Layer of INTERBUStakes into account the support of both data types occurring in sensor/actuator technology - the cyclicprocess data and the non-cyclic parameters. The interface to the application is provided by layer 7.
An important feature of the Data Link Layer of INTERBUS is the deterministics, i.e. the time guarantee withwhich the cyclic data transport between the remote devices takes place. INTERBUS is based on thesummation-frame procedure, which is assigned to the class of collision-free TDMA transmissionprocedures (TDMA: time division multiple access). This means that every device is allocated a time slot
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
suited to its function, which makes it simple to calculate the transmission time as the sum of all the timeslots. Additional time slots can be defined for connection-mode data blocks "on demand". In this way, datablocks of several Mbytes can be transmitted with INTERBUS, without altering the cyclically short scanningreference for the process data types. The independence of these two data types from one another isdecisive for the performance capability of the INTERBUS protocol and the ability to realize closed-loopcontrol tasks via this protocol. In combination with each other, these protocol characteristics permit therealization of a seamless network covering control systems, intelligent field devices, and single sensorsand actuators. In addition, the summation-frame procedure guarantees that the process image isconsistent between all devices, since all input data stems from the same scan time and all output data fromthe devices is received at the same time. A further advantage of INTERBUS is the high rate of efficiency ofthe protocol, i.e. that the additional amount of data (overhead) needed to save and synchronize data issmall in comparison to the amount of user data. In contrast to other bus protocols, the physicaltransmission rate can be kept low. This is reflected directly in the costs for components and cables as wellas in the improved EMC behavior. On the other hand, however, this also shows the unique potential thatINTERBUS can offer when the transmission rate is increased. It is not necessary in this case tocompensate for the protocol over-head by increasing the transmission rate in order to obtain an adequatethroughput of data.
3.0.5 Technical Implementation of the Transmission Protocol
The summation-frame procedure explained above is realized in INTERBUS by means of a registerstructure. Every INTERBUS device joins the ring via a register, the length of which is determined by theamount of process data points of the device. By coupling all the devices together, a ring is created, thelength and structure of which corresponds exactly to the configuration of the user data field in thesummation-frame message.The process output data for peripheral equipment is placed in the output bufferof the master according to the physical order of the connected output devices. A transmission cycle beginswith a data sequence. This data sequence contains the loopback word on the transmission side, followedby the output data.
During data output, the return flow of process information is simultaneously entered into the input buffer ofthe master as input data. After output of the entire summation- frame and simultaneous input of the same,all output data is correctly positioned in the individual devices. The subsequent 32-bit long frame checksequence (FCS) serves to check the user data transferred to the data sequence. This data save is carriedout using a check sum procedure with a CRC polynome in acc. with CCITT. Due to the point-to-pointstructure, the error checking mechanism always takes place between two neighboring devices. Controlledby the frame check sequence, the exchange and comparison of the CRC polynomial remainder is thencarried out simultaneously for all devices, so that one single transmission overhead is generated by the CRcheck, which is effective for the whole system. The check sum status in the remaining 16 bits of the FCS is
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
first transmitted. This check sum status is used by every device to report both transmission errors of itsown which it recognizes to the next device, and to recognize errors from the previous device. If the checksum status shows no recognized transmission errors, the data in the registers is released to theapplication. New input data to be transmitted continues to be requested by the application. In addition tothe data cycle for the transmission of user data as described above, an identification cycle is also definedin the Data Link Layer of INTERBUS. This cycle acts as the bus management. Each bus device has aLayer 2 identification code, which gives information as to the type of device and its range of user data. Theindependent configuration of the bus system is carried out by a sequence of identification cycles which thebus master initiates in order to read in the identification of the remote devices. Using the identification coderead in, the summation-frame configuration for the data cycle can be established. Layer 1 of INTERBUSfunctions with an asynchronous start/stop procedure. One header, which contains additional informationsuch as frame end identification, function code and message type, is added to 8 information bits andtransmitted as a data message. During breaks in transmission in which there is no output of user data fromthe master, the regular data flow is filled up with status messages. They do not contain any Layer 2 dataand serve mainly to guarantee permanent activity on the transmission medium. If this data activity isinterrupted for a period of > than 20 ms, it is interpreted by all the devices as an interruption in the sys-tem. As a result, the devices are switched to a defined and safe reset status, i.e. all devices are switched tothe safe status within a very short time in the event of an interruption in the system or failure of thecontroller board.
3.0.6 The User Interface
The protocol and topology characteristics of the INTERBUS system described above ensure for the firsttime an innovative integration of the demand for cyclic I/O data transport and non-cyclic message transportin a single system, while at the same time taking into account, and fulfilling, the demands of the entire fieldof industrial sensors/actuators. This is the prerequisite for the realization of a uniform network in this area.However, easy access to the network data is of at least the same importance to the bus system user. Inorder to create a user-approved solution, the INTERBUS application interface has also been divided, inaccordance with the two data types. INTERBUS responds directly to the user demand for process mappingof simple, transparent process data. A cyclic program in the bus master continuously updates the processdata and makes it available to the user in the control system in the form of an I/O process image. That is tosay, process data can be accessed with standard logic and transfer commands in the relevant PLC syntax.This direct memory access helps to avoid lengthy service access procedures, which would otherwise havea drastic effect on the real-time characteristics of the process data protocol. For freely programmablecomputers, as for example PCs, the process data in the interface storage (DPM) can be accessed directlyusing drive functions or standardized software interfaces (DDE, OPC, Open Control). When accessingprocess data, the user of the INTERBUS system will not notice any difference between serial cabling andthe traditional parallel cabling. Users are not required to familiarize themselves with complexcommunication structures.
3.0.6.1 PMS Services
Open communication can only be achieved with standardized, universal communication services that meetthe demands of all devices and applications. Such standardized agreements already exist in the area offactory networks, within the framework of the MMS (Manufacturing Message Specification) used by MAP.MMS is an application layer for communication networks with a universal and structured design, so that itcan be implemented regardless of the device or application. Based on the structure of the MMS, acompatible subset of the defined communication services has now been created for the INTERBUS systemand is called PMS (Peripherals Message Specification).
The about 25 PMS services permit simple communication with intelligent process devices. Services areavailable, amongst other things, for establishing and monitoring communication links (contextmanagement), reading and writing variables or parameters (for example: read/write), as well as starting upprograms (e.g., download/start/stop). The number of services can be easily extended for certain devices.Due to the continuously running cyclic I/O protocol, a device operat- ing in the INTERBUS network cancarry out services on the PMS level (server), as well as transmitting services autonomously (client).
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
With programmable logic controllers, access to the PMS communication services from the applicationprograms is not carried out via parallel I/Os as with process data, but is realized via so-called functionblocks (data handling blocks). In addition to this, the communication services can be predefined during theproject planning of the system and then need only be activated as saved function blocks via bit commandswhen the sytem is put into operation. This simple interface saves the user from making up complicateddata handling routines to exchange communication data, and reduces the use of communication servicesto the handling of logic operations.
The standardized use of the universal PMS in the INTERBUS network not only permits direct access toprocess data, but also provides the desired communication link between simple sensors/actuators andintelligent field devices and control systems. This hybrid procedure, with its easy memory access toprocess data, permits program structures already available in parallel cabling to be transferred directly intoserial networks. Thus, users can even respond to intelligent network devices via process data alone. In thismanner, for example, drive controllers on INTERBUS can exchange setpoint and actual values for therotational speed via the process data channel. This means that the rotational speed setpoint can still bespecified from the PLC program as an analog value, as was previously the case.
Due to the close relationship between the PMS and the standardized user interface in fieldbus and MAPnetworks, INTERBUS can be integrated into a universal network concept, from the factory level through theprocess and cell level to the sensors/actu- ators, thereby providing, for example, an ideal supplement to theEthernet standards of the higher commmunication levels which are quite common today.
[Top] [Prev] [Next]
Copyright © 1997, INTERBUS Club All rights reserved.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
[Top] [Prev] [Next]
3.0.7 Practical Application of INTERBUS
The following example of an application in the field of motion control is designed to illustrate theINTERBUS system characteristics described above. One of the main demands during the development ofthe INTERBUS system was that, regardless of whether a serial bus system or parallel cabling was used,the task of the PLC application programmer remained the same. The following example illustrates howINTERBUS meets these demands.
In the previous illustration, the sample system is first shown with the usual parallel cabling. A conveyor beltis driven by a drive, which is PLC-controlled and supplied with setpoint values. Binary limit switches arealso scanned in the system.
The parallel lines for binary information transmission and analog transmission paths, which are particularlysusceptible to faults, are not required in the serial system. All signals are transmitted to the control systemvia the INTERBUS network.
The programming tables show that exactly the same program can be used for both conventional and serialcabling. The rotational speed setpoint information, which is analog data with conventional cabling, is nowtransmitted to the drive as a process data item. The transmission of complex parameters is just as simpleas writing a program for process data. The signal interface previously described is now used to activate theaction blocks.
It is possible, for example, to define the complete initialization of the drive as a closed "action". Using theconvenient INTERBUS configuration tool CMD (Configuration, Monitoring and Diagnostics), which will bedescribed in more detail later, the initialization data is transferred from a PC via the universal V.24interface, loaded onto the INTERBUS controller board and combined into a single "action block". Singlecontrol bits are then allocated to these "actions" in the so-called signal interface to the PLC. All networkactivities and communication services linked to the initialization of the drive can then be triggered by settinga single bit from the PLC program and controlled by interrogating a further bit. Thus, complexcommunication is reduced to the PLC user’s usual handling of binary logics. The user only carries out theactual function of device parameterization; the background communication services are automatically
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
generated and activated by the system.
3.0.8 Standardized Start up, Operation and Diagnostics with the INTERBUS Software CMD
In accordance with the demand for manufacturer neutrality, a bus system for open and flexible PLCarchitectures must also offer the user a concept for uniform and, above all, manufacturer-independentsystem handling and diagnostics. The openness of modern bus systems usually stops short of theconfiguration and diagnostics of the connected control systems and devices. Bus devices are becomingincreasingly complex and many now require special operation and diagnostic tools in order to makepractical use of all their functions. Nowadays, virtually all PLC and device manufacturers offer their ownsoftware packages, which means it is extremely difficult for the user to integrate single components into anetwork or start up the network as a whole. This plight is particularly obvious when it comes to diagnosticsor service, when you cannot afford any delays or operational problems. The user of a bus system is oftenconfront- ed with a multitude of different diagnostic concepts and aids which make it more difficult toeliminate the error quickly.
A start up and diagnostic software, CMD (Configuration Monitoring Diagnostics) was developed forINTERBUS, the main feat- ures of which lie in the independence from the control system used and theflexibility toward program extensions, new functions and add-on programs.
CMD is an aid which can be utilized during the whole life cycle of a system whenever service becomesnecessary, whether in the project planning phase, at start up, for operational monitoring, or in theevaluation of diagnostic data. In addition, it is possible to program small process data preprocessingroutines directly on the controller board, using the IEC 1131 programming language, "Function BlockDiagram". The user can define the INTERBUS system configuration in the project planning phase with theCMD software. Program addresses, via which the control program can later access the remote I/Os, canbe allocated in CMD. Parameterization and operation of the INTERBUS controller board are carried outhere just as, for example, the read-out and evaluation of the diagnostic data when the system is operating.With the help of a monitoring function, a functional test for subsystems can be carried out.
This software is accordingly used by different groups such as project planners, start up technicians,electrical fitters and service technicians. This means that new and time-consuming training and gettingused to different software tools is no longer necessary. All INTERBUS project data is stored centrally underCMD and made available to all groups involved in the operation of the system. CMD can run under theoperating systems Windows 3.1 / 3.11, Windows 95, and Windows NT 4.0 on any standard PC. Couplingto the control system used by the user or to the INTERBUS controller board integrated in this system isrealized via a standardized RS 232 interface within the INTERBUS network. In this way, it is guaranteedthat various controller boards and makes of control systems can be operated by just one software tool.
All INTERBUS-capable devices from currently over 700 device manufacturers can be supported by CMD.The device manufacturers generally make device data, sometimes called device description, available inthe form of an electronic data sheet. This can be read in and processed directly by the CMD software. The
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
INTERBUS supplier index (CD-ROM) already contains a multitude of such descriptions, as well as acomplete overview of INTERBUS-compatible devices on the market. In the case of new developments, theuser himself can create these device descriptions and file them in the CMD database.
As a result of standardized software interfaces within the operating software, it is possible to add furtherfunctions or new add-on programs from any manufacturer at all times. Thus, if a manufacturer supplies aparticular device with a operational program, the user can easily integrate this program directly intoINTERBUS CMD. In order to standardize, for example, the operation and selection of particular groups ofdevices, e.g., frequency inverters and drives, the manufacturers of drives have joined together in theINTERBUS Club to form a user group, and have agreed on profiles according to which these devices canbe addressed. A consequence of this has been a joint add-on program within the framework of CMD. Thebenefit to the user: a uniform environment for the operation and parameterization of frequency invertersand drives from various manufacturers. Such a concept can of course also be realized for other devicegroups.
This example shows once more the benefit of open automation concepts for the user.
3.0.9 INTERBUS Loop
Particularly in the integration of individual sensors and actuators, many established field bus protocols failand call for "a downward extension". The standardized INTERBUS protocol enables the amount of data perdevice to be reduced as desired, without reducing the efficiency and therefore the data throughput.INTERBUS does not need to be supplemented here by another bus system with a new protocol, but can becontinued simply and consistently, right up to the final sensor without an interruption in the system.Cost-effective connection of the single sensors and actuators has been achieved simply by changing thetransmission method in this area to suit the application conditions.
This transmission technique is known as INTERBUS Loop. INTERBUS Loop links the individual devicessuch as sensors, actuators but also, for example, drives and encoders to a ring, with a simple two-wireunshielded cable. The Physical Layer, which has now been adapted to the application, carries the datainformation and the 24 V power supply simultaneously to up to 64 sensors by means of one cable with twoconductors.
The data is transmitted in the form of load independent current signals, which considerably increases theimmunity to interference compared to the voltage signals normally used. Thus, INTERBUS Loop is soimmune to interference that even in an industrial environment, it can be operated fault-free withoutshielding! Despite the lack of shielding and a bus cycle of 500 kbit/s, all components receive the CE mark.
A special bus terminal module enables connection to the INTERBUS remote bus, whereby INTERBUSLoop, together with all other INTERBUS products, can be used on a common bus. Also, severalINTERBUS Loop segments per INTERBUS remote bus can be interconnected. If, for example, there aremore than 64 INTERBUS Loop-capable components to be integrated, the user simply adds a new busterminal module. Additional measures such as the installation of special power units do not have to betaken into account and paid for over again by the user. Besides the conversion to the new bus physics, theINTERBUS Loop bus terminal module also takes over the feed-in of the 24 V supply voltage into the ring.In contrast to the INTERBUS remote bus, the data in the Loop is not sent and returned in one cable. In theINTERBUS Loop, the data ring has been opened to form an actual, physical ring. Thus, it is possible totransmit the INTERBUS protocol via a cable with only two wires.
Up to 10 m can lie between two devices and an INTERBUS Loop can reach in total up to 100 m in length.Together with the possible transmission ranges of INTERBUS, the user can now cover almost anyapplication which may occur, whether near or not.
There are two areas of application for INTERBUS Loop: on the one hand it connects individual devicesdirectly in the system, so the bus connection must be carried out in IP 65. On the other hand, theINTERBUS Loop cable is routed into the switching cabinet and connects the components there. Thisenables not only contactors and miniature circuit breakers to be wired more easily, but also indication andcontrol devices such as switches, keys or signal lamps, which are equipped with a Loop chip.
The protocol compatibility of INTERBUS Loop means it can be used with all other INTERBUS devices. AllINTERBUS-compatible control systems can therefore be implemented as a master. Problem-freeexpansion of an existing INTERBUS system is also possible. INTERBUS Loop devices are fully functional
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
INTERBUS devices, which still have all the advantages of the INTERBUS system. No sensor functions areexcluded from INTERBUS Loop. It even permits integration of complex sensors e.g., those deliveringnumerous measurement values which can sometimes be continuously modified. Right from the start, it isthus not restricted to digital signals.
Because the connection of INTERBUS Loop to a larger INTERBUS system does not require any protocolconversion, there is no need for costly gateways, and data scanning is perfectly synchronized throughoutthe system. The high data throughput unsurpassed by other manufacturers also remains with theINTERBUS Loop, since it also functions at 500 kbit/s as effectively as usual. The features mentioned so fardistinguish INTERBUS from other systems which realize the same task with at least two different protocols.In the face of this "assortment" of partial solutions offered by other systems, INTERBUS represents astandardized, simple and seamless bus system.
Using the newly developed connection technique (QUICKON), the bus cable can be connected quickly andreliably without tools. The connection can also be disconnected as often as desired and is thus notdependent on a questionable self-healing of the cable. The fact that the cables can be easily disconnectedfrom connections will certainly make it easier for the user when searching for an error, e.g. a short circuit.
3.0.10 Standardized Networking with INTERBUS
The fact that single, discrete sensors and actuators can be integrated in the INTERBUS network by simplyadapting the transmission method, and not affecting the standard INTERBUS protocol, clearlydemonstrates the performance capabilities of the INTERBUS protocol and its provision for extension. Inorder to provide a complete solution for an automation task, it is not only necessary to network fielddevices right down to single sensors and actuators, but also equally important to include control systems,computers, high-tech controllers and complex field devices in the universal network concept. By way offulfilling these requirements, as well as being capable of the afore-mentioned cyclic, time-equidistantscanning of I/O data, the INTERBUS protocol is also optionally capable of non-cyclic, demand-orientedcommunication with larger amounts of data. This parameter channel, also called PCP (PeripheralsCommunication Protocol), together with the cyclic I/O protocol, provides the complete solution to anautomation task. The following example of an application in the automotive industry clearly demonstratesthis performance capability. This application was discussed in working groups comprising automotivemanufacturers, welding and robot controller manufacturers and discussed until a solution was reached.The task was to network the following devices and to transmit a variety of data. The peripheral devices ofthe PLC, which are provided to control the system, comprise 12 welding controllers, 8 robot controllers, aswell as four valve maintolds, a wrenching controller, 10 control cabinets with approx. 300 discrete I/Os, twoservo drives, two operator stations and a bolt welding facility. The PLC has to exchange cyclic I/O data withall these devices. The requirement here is that this cyclic data exchange must be carried out in a time of <10 ms. In addition to the transfer of cyclic data, it is also necessary for data and programs to be stored on ahigher-level PC. The task includes that each of the 12 welding controllers must be supplied with 100 kbyteprograms, while the programs for the robot controllers can even be as large as 2 Mbytes. The thirdrequirement was the need for autonomous operation of the I/Os directly connected to the robot controller,irrespective of the operating capability of the PLC and the rest of the network.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The working group’s discussions resulted in the topology described below.
It is decisive that overall communication for all tasks is handled over a standardized INTERBUS network.For performance reasons, INTERBUS has been realized as a logical network comprising three physicalsegments. The coupling between these individual segments is carried out by "System Couplers"- a specialfeature of the INTERBUS system.
This system coupler has simultaneous master and slave functions for the INTERBUS network and caneven provide a third interface to the control system. In this manner, data can be exchanged between twophysical bus segments by avoiding the control system. The configuration can be carried out assuming alogical seamless system.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
Furthermore, it is possible, e.g. in the robot controller, to receive data directly from the PLC or to supply I/Odata from a secondary robot controller to the network. The illustrated topology permits the following systemcharacteristics. The cyclic data exchange between PLC and I/O level is carried out in a cycle time of < 6ms. Parallel to this cyclic data transfer, for example, the programs of all 12 welding controllers can besimultaneously transferred in 3 minutes. When the programs alone can be transferred to only one robot, itis even possible to transfer up to 2 Mbytes in approx. 3 minutes. These program down-loading times areapproximately the same as those achieved by field bus systems, such as PROFIBUS, which are speciallydesigned to handle the task of transferring large data blocks. The great advantage of the INTERBUSsystem is that this program downloading does not affect the cyclic scanning of I/O data in any way, i.e.,even if 2 Mbyte programs are loaded to the robot, the limit switch is still scanned at a fixed time interval of6 ms. This characteristic cannot be ensured by any other bus system on the market. The peripheralequipment at the level below the robot even has a scan time of 1 ms, whereby, as already shown, it ispossible for the PLC to directly access the I/Os at the level below the robot.
This topology is far from being just theory. In a similar form, reputable automotive manufacturers arealready putting it to the practical test, in actual plants.
The characteristics of the INTERBUS system described clearly show the performance capability and theperformance reserves of the protocol, which ensure the future reliability and stability of INTERBUS. Theattempts of other systems to accommodate the growing demand of the market by continually changing theprotocol, the baud rate and the transmission methods, has led to the creation of an assortment ofincompatible partial solutions. When realizing an automation task with, e.g., PROFIBUS, this can soon leadto the implementation of three completely different networks with different cables, different handling,different baud rates, different devices and, above all, completely different diagnostic and start up tools. Inthe face of this assortment of partial solutions, INTERBUS offers a seamless solution, with one protocol,one baud rate, the same devices and the standard operating tool, INTERBUS CMD. INTERBUS providesthe overall solution for automation tasks, from networking the control systems down to the "last" singlesensor and actuator. The communication tasks range from program storage and machine data acquisitionthrough typical "real time control tasks" to complete control loops. For the system user, this ultimatelymeans reliability and real savings, in terms of time, material, stock and personnel, during the entire lifecycle of the machine or plant.
3.0.11 Interoperation with Device Profiles
To achieve an interoperation of devices from various manufacturers across a common network, it isnecessary to standardize the communication characteristics of these devices. This alone, however, doesnot ensure error-free operation of these devices with one another and arbitrary replacement of thesedevices by those from different manufacturers. A truly open and flexible system requires, over and above
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
the standardization of communications and networking, also conventions on device functionality. This ismade clear by a motion control example.
Two drives from different manufacturers are networked via a common bus. Both drives are supplied with arotational speed setpoint. In this case 4000 revolutions. Because of its internal definitions, drive 1 interpretsthe transmitted data as a 16 bit integer value. However, drive 2 interprets the same data as a 12 bit integervalue. The result of transmitting the same data to different devices in the first case is a rate of 4000revolutions; in the second case the drive rotates in reverse at 96 revolutions. The resulting problem lies inthe non-standardization of the data structures and device functions. INTERBUS solves this problem byusing common definitions worked out by groups of manufacturers. These device definitions are also knownas device profiles, which are available from INTERBUS for the following fields :
· Motion (DRIVECOM)
· Welding controllers (WELDCOM)
· Operator terminals and displays control (MMICOM)
· Robot controllers
· Digitisers and angle encoders
· Process controllers
· General sensors and actuators
· Open control
All of these profiles have been established by working groups consisting of device manufacturers andusers. They have therefore been defined keeping close to the practise and reflect the requirements fromspecifie applications of networked field devices.
The fact that these profiles are used in practise can be shown by the example of the DRIVECOM profile.Thirty-nine drive manufacturers have joined to form a group and standardized the most important functionsof their devices in a profile known as the DRIVECOM Motion Control Profile. The practical result of thisstandardization is that a DRIVECOM profile compliant drive from manufacturer A can be exchanged for adrive from manufacturer B and it is guaranteed that the same control program will work with the new drivein the same way. The DRIVECOM functions are standardized for servo drives, frequency inverters and D.C. drives. They are already used in many thousands of applications and have been adapted to other bussystems (e.g., CAN, FIP, etc.). The device functions defined in the profiles are, in the case of DRIVECOM,confirmed by a certificate issued after passing a test carried out by an independent test authority. The userof such devices can thus be sure that these certified devices will function together on the same networkwithout problems. The INTERBUS profiles guarantee the reliable operation of different devices fromvarious manufacturers on the network, otherwise known as "interoperability". Just like the INTERBUSsoftware, INTERBUS-CMD, the profiles are important elements for an open and flexible control systemtechnology. All profiles are available from the INTERBUS Club.
3.0.12 INTERBUS Products and Manufacturers
Since 1987, INTERBUS has established itself on the market as a sensor/actuator bus standard. TheINTERBUS protocol specification has remained stable or been expanded in a compatible manner sincethen. Today’s devices can still be used without problems with devices of the first generation. This stabilitywas a major requirement for the fact that well over 700 manufacturers of devices offer more than 1000compatible INTERBUS devices on the market. Potential users of the INTERBUS system have the choice ofa large number of tried and tested INTERBUS-compatible devices. In the field of control systems, it iscontroller boards to Siemens, Bosch, Groupe Schneider (AEG, Modicon, Telemechanique, Square-D),Klöckner-Moeller, IPC, GE-Fanuc, Allen-Bradley, Hitachi, Mitsubishi and many others - INTERBUS fits onover 80% of the PLCs on the market. Apart from these programmable logic controllers, INTERBUS canalso be connected to open computing systems such as VMEbus systems and of course IBM-compatiblePCs. controller boards to other control systems are currently under development. In the field of distributedI/O devices, the available devices range from complex high-tech controllers, such as robot controllers,welding controllers and automatic wrenching controllers, drives, positioning controllers, air and paint flowcontrollers, measuring instruments, identification systems, pneumatic and hydraulic components, to amultitude of distributed I/O devices from diverse manufacturers. With such distributed I/O modules, allprocess signals, whether of a binary or analog nature, can be connected to INTERBUS. The entirespectrum of manufacturers of INTERBUS-compatible devices is listed in the INTERBUS supplier index,which is available both as a printed document and as an electronic directory on CD. This broad support forthe INTERBUS system, especially evident among small to medium-sized companies, offers the user a widechoice of products and manufacturers.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
[Top] [Prev] [Next]
Copyright © 1997, INTERBUS Club All rights reserved.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
[Top] [Prev] [Next]
3.1 Open Architecture in the PLC Environment using INTERBUS
With ever increasing internationalization, shorter planning and development phases, stricter customerprovisions and rising cost pressure, it is becoming more and more important to reduce engineering times,standardize handling and integrate open system solutions.
This trend has been noticeable for some time now on the PC market. Here various manufacturers offertheir components on a standardized platform and open a wide spectrum of products to the users. To thisend, INTERBUS offers a neutral fieldbus platform and, at the same time, goes a long way towardstandardization and application-oriented functionality.
Open planning with INTERBUS means:
with the integration of INTERBUS and the system, the control and industrial PC technology becomes aninnovative system solution for all major makes of control systems, which together have a market share ofover 80%. The basis is formed by the Generation 4 INTERBUS controller boards. They form the uniformperipheral access to the control systems.
Simple "Plug and Play" technology combined with extensive diagnostic functions which check the entiresystem autonomously and report interferences. Parameterization and operation of the functions is identicalfor all controller boards. The software tool, IBS CMD (Configuration Monitoring Diagnostics), which can berun under Windows, serves as a bus configurator in the project planning phase. Bus configuration, addressallocation for inputs and outputs, documentation of the same and parameterization of intelligent devices inthe network is carried out via an interactive graphic environment.
The pure substitution of parallel input and output boards to create bus-capable components is extendedwith INTERBUS automated systems by the additional integration in an intelligent bus system with datapreprocessing functions. Simply parameterize using IBS CMD in acc. with IEC 1131 and acontrol-independent coprocessor is available to your system.
With the INTERBUS data preprocessing, the functional machine layer provides the interface to theapplication program. The system function is programmed on the control side and sent to the controllerboard via the input/output layer. The machine-relevant data which is functionally connected with thecomponents in the system is projected onto the host controller board (e.g., fast switching off of an outputport for positioning).
At its simplest, this would be interconnections between sensors and actuators which are wired via the
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
INTERBUS system. Further, parameter data from intelligent field devices such as frequency inverters orrobot controllers, right up to control information such as interlocking of the mechanical processes aretransmitted. The advantages of the extensive possibilities of parameterization pay off when there is achange from one system to another control system or to an industrial PC. It is now only the sequence ofmachines that remains to be adapted to the new environment.
The system-specific functions, the INTERBUS parameterization, operation and diagnostics, as well asparameterization of the intelligent devices, are carried out directly. Changing a control system does notmean replanning the system is wiring. A "mouse click" in IBS CMD on the new controller board is sufficient.
The compatibility of the control system as a result of the peripheral level standardized via INTERBUS hasproven worthwhile in a variety of applications. Plants of a leading automotive manufacturer have beenequipped with a different control technique, for example. Parameterization of the existing INTERBUSsystem, including the preprocessing functions, documentation and cabling have remained the same andare simply coupled with the altered busmaster. The same parameterization, start up and operation of theentire system help to secure investments and react flexibly to the market. The extensive range of functionsof the INTERBUS controller boards supports innovative applications so as to be one step ahead in themarket.
3.2 Open Control
Large international users, e.g., GM, Chrysler or VW, have recognized the disadvantages of themanufacturer-specific control systems dominating the market today and favor systems based on open PCarchitecture and an open standardized field- bus system for the future. In order to place particularemphasis on their demands, the OMAC paper (Open Modular Architecture for Controls) was formulated byGeneral Motors and Chrysler. Open modular automation systems based on PC architectures thus, for thefirst time, give the user the opportunity to escape from the dependence on control systems manufacturersstill dominating the market. He can now select the most suitable product for his application with the bestpossible application know-how from a wide range of components from various manufacturers. With the aimof fulfilling the demands of the users and creating an open automation standard for the future, the OpenControl User Group was founded by 17 companies on 8 March, 1996, with the INTERBUS-S Club e.V. aspatron.
Within the Open Control User Group, work groups for marketing and technology were set up. The workgroup for technology is involved in the definition of standardized interfaces between the components of acomplete automation solution. These components are, for example, visualization and control software, aswell as runtime systems, configuration and programming tools, as well as peripheral componentsconnected via a fieldbus. Other major components are the open PC architecture and the operating systemused with it.
These standards were formulated in the technology work group meetings and are now available as a firstspecification. The assumption was that three interface levels would develop within the automation solution.These are:
1. Interfaces between the remote runtime systems, which have to exchange data deterministically withinmilliseconds.
2. Interfaces between the runtime systems and the superimposed application (e.g., visualization), wheredata has to be exchanged within intervals ranging from milliseconds to seconds.
3. Interfaces between the engineering tools, which are thus in a position to access a data base with thevariable definitions and variable parameters.
In order to put this interface definition into practise, the CALL interface (Control Application Link Layer) wasformulated by the Open Control User Group. The CALL specification is divided parallel to the interfacesdescribed above into the CALL-P (periphery), CALL-R (runtime) and CALL-E (engineering).
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
With the aid of the CALL interface definition of Open Control, it is now possible to create automationsolutions individually with products from various manufacturers, without experiencing problems with theinterface. The common data base, for example, enables a variable which has been defined usingmanufacturer A’s programming tool to be used immediately in the visualization software of manufacturer B.This means that double definitions of variables in different tools, an annoying occurence susceptible toerrors, will disappear.
The Open Control User Group has, from the start, aimed to base its interface definition on existingstandards. In this way, tools available now can also work with tools based on Open Control. It is thuspossible, with OLE/DCOM technology, common in Windows NT (used by Open Control), to make dataavailable for other applications. In this way, production piece numbers and the quality of the products caneasily be evaluated in, for example, an Excel table. Of course an interface to Visual Basic or Visual C++applications is also possible without problems.
CALL-R is based on the definitions laid down by the OPC Foundation (OLE for Process Control). Atpresent, the OPC Foundation is made up of over 140 mainly American member companies. By using theOPC definition, there is a guarantee that even applications that only come up to the OPC standard can beintegrated into Open Control applications. In addition to the definitions made in OPC, CALL-P is specifiedby Open Control, which means that the peripherals connected via the fieldbus are incorporated in thecomplete automation process.
As a result of the pragmatic approach in the Open Control User Group and consistent contact with theusers, results were achieved very quickly. On the basis of this first specification, prototypes are alreadybeing presented to the public, e.g. at the SPS/IPC/DRIVES at the end of November, 1996 in Sindelfingen,Germany.
The rapid growth in the number of members, bringing the Open Control User Group up to over 80international companies in only a few months, proves that the Open Control User Group is on the right pathwith its work. This and the active participation of the users makes it obvious that the PC is defining thecontrol solution of the future.
In 1994, the world market for programmable logic control systems was 5 billion US $ (acc. to ARC:Automation Research Corporation, Massachussets). Five manufacturers shared 2/3 of the marketworldwide. Each of these manufacturers concentrates on a particular geographic area and offers aself-contained solution. For this reason, machine and plant engineers, who have to react flexibly to thewishes of their clients, must equip their machines that have the same functions with different automationsolutions. Thus, the machine that is sold in Germany is equipped with a German make of control systemand that which is sold in the US with an American one. This results in a considerable increase in the costsof the system conception, since project planning, programming, training, stock keeping, service, and so onvary from manufacturer to manufacturer and therefore, have to be counted twice. Open Control offers away out of this situation, as it is based on open PC architecture, with a world market volume of over 250billion US $ and several hundred suppliers. This means that Open Control-based automation solutions canbe individually equipped with components as desired by the clients.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The reliable interaction of all components is guaranteed by the Open Control CALL specification and thecertified interfaces of the various suppliers based on this. The control hardware is thus no longer the solelydecisive part of the automation solution, but can, like all other components, be exchanged in almost anyway. The efficiency of the control system will therefore no longer be solely dependent on the innovativeenergy of the individual control manufacturers in future; instead it will grow with the innovation cycles,which are already customary in the PC industry. Furthermore, the mass production common in this fieldmeans that lower prices and better product quality can be guaranteed in the long run. On balance, it can besaid that the future of the automation solution via Open Control definitions has already become reality. Itwill therefore supersede modern automation technology, which still consists of a PLC and an industrial PCfor visualization.
3.2.1 INTERBUS with PC-based Control Technology
Open Control as a PC-based control platform relies on the following three established basic technologies:
1. Automation hardware based on standard PC architecture.
With the success of the PC architecture introduced in the eighties, this has established itself as thestandard hardware platform worldwide. Nowadays, PC systems are used a million times a day and haveproven themselves in a variety of tasks. The large share in the market of PC systems, independent of anyspecial field, has resulted in a multitude of different components. This wide spectrum of technologyavailable worldwide enables the configuration and use of systems which can be scaled in a flexible mannerand an exemplary cost effectiveness. In conjunction with the operat- ing system Windows, the PC isnowadays also the basis for software for all tasks and applications to which thousands have access. Due toits graphic design, Windows is the ideal platform for tasks involving visualization and further providesalways identical operation and operator prompting.
2.Open peripheral system on the basis of INTERBUS technology.
In modern production and process engineering, decentralization nowadays plays a central role. INTERBUStechnology, specially developed for this area in industrial automation, has influenced this development fromthe start and proven itself as a stable protocol on the market since 1987. INTERBUS, with more than 1.2million networked devices in various applications, is now already the standard peripheral system for open,manufacturer-neutral automation structures.
The consistent further development of this protocol optimized for the field of sensors/actuators, and the factthat it is strictly aimed at the needs of the users and applications have steadily expanded the fields in whichINTERBUS systems can be employed. The efficiency of INTERBUS technology already enables, forexample, the standardized networking within a seamless system from the last limit switch and sensor,through drive and indicator devices, and operator panels to process regulators, and robot control systems.The basis for this is the unique hybrid protocol structure of INTERBUS, which makes it possible to transmitdata blocks of up to several 100 kbytes and simultaneously to read the highly dynamic sensor and actuatortechnology with their demands of millisecond scan cycles. In this way, both control information andadministrative messages e.g., programs or parameter records, can be downloaded at the same timewithout influencing each other.
3. Programming system based on the inter- national standard IEC 1131-3.
In the case of classical control systems from traditional suppliers, the programming system is alwaysdirectly linked to this specific control series of the manufacturer. Parallel to the development of the PLCsthemselves, this has in the past led to an immense diversity of programming methods and dialects. At thesame time, the size of an application program grew with the increasing degree of automation in 10 yearsby about a hundred times. In order to master the complexity of the modern control systems from aneconomic stand point, the standard IEC 1131 "Programmable Controller" was formulated under thepatronage of the "International Electrotechnical Commission". This standard is not merely another newprogramming language, but unites the experience which has been collected in millions of applications inPLC programming and partly described in national standards e.g., France (Grafcet), USA, (NEMA ICS 3304), and Germany (DIN 40719, 19239 and VDI 2880). Based on the standardized structures of a modernautomation system, IEC 1131 provides, on the one hand, the modern graphic programming languages,Sequential Function Chart (SFC), Ladder Diagram (LD) and Function Block Diagram (FBD), and on theother hand, two textual languages, the classic Instruction List (IL) and the modern Structured Text (ST).
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The availability of this comprehensive standard reduces not only the cost of producing and updating thecontrol software itself but also the costs for training the programming and service staff. Open Control unitesthese established standards: PC architecture, INTERBUS technology and the IEC 1131 programmingmodel to form a common platform for a forward-looking and innovative automation system. The broad baseprovided by Open Control does justice to the ever growing demands of the international market, with itsshorter and shorter innovation cycles and aggressive price movements.
The software structure illustrated in figure shows the design, which is modular in two respects. Dependingon the application, we distinguish between engineering and runtime components, whereby these too havea modular structure. The engineering part contains the components for programming, system configurationand system diagnostics, components for the production of visualization graphics and further componentssuch as robot control systems, or CNC controllers, depending on the system. All these components workunder a common engineering environment with common project administration and exchange their data viaa common data base. The open interface architecture means that new components can be integrated atany time or existing ones exchanged.
[Top] [Prev] [Next]
Copyright © 1997, INTERBUS Club All rights reserved.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
[Top] [Prev]
4. INTERBUS in Action
In 1997, INTERBUS will be used in over 120000 systems with almost 1.5 million networked field devices. Itis thus the most widely spread fieldbus standard worldwide. The fields of application for the INTERBUSsystem include all areas of industrial automation technology. It is used in production engineering, inmechanical engineering, in warehousing and logistics systems, in the food, timber and paper industries, inindustrial process systems including hazardous areas, and also in systems which require fault-tolerantsystems with a very high degree of availability. The list of INTERBUS users includes a great number oflarge well-known enterprises throughout the world. In the European automotive industry, about 80% of allbody shop and welding plants are realized with INTERBUS systems. All large international automotivemanufacturers rely on INTERBUS; in North, Central and South America, in Asia and in all countries inEurope. Of prime importance for the acceptance of INTERBUS is - apart from all the technical advantages- the stability and universality of the system. In the long term, stability guarantees reliable operation, a highdegree of system availability and a drastic reduction in idling.
The universality results in a standardized bus topology, since the entire automation task is realized whollywith INTERBUS, without other bus systems or patched together partial solutions.
5. The Way to INTERBUS- compatible Devices
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
An open bus system like INTERBUS depends on the support of a large number of manufacturers. Today,INTERBUS is already supported by over 700 manufacturers of all types of control systems. In order tomake the introduction of INTERBUS technology as easy as possible for these manufacturers, theINTERBUS Support Center was established as a service group to support them with the integration ofINTERBUS. The INTERBUS Support Center today offers a graded concept of implementation tools,support services, protocol chips and complete interfaces. This comprehensive range of solutions allowsdevice manufacturers to implement INTERBUS interfaces with prior knowledge of costs.
a) Slave Hardware
A basic requirement for an acceptable network concept is the existence of highly integrated circuits forprotocol handling. For this reason, protocol chips for slave and master interfaces have been developed forthe INTERBUS system. These protocol chips are freely available and are offered with comprehensivedocumentation. The protocol chip for slave interfacing implements the complete cyclical I/O protocol and isa direct interface to process data. This chip can directly connect up to 16 binary input or output sources.Furthermore, the implementation of the simplest I/O devices for the INTERBUS system is optimallysupported. As figure 20 shows, only a few external components are required in addition to the protocolchip. This very simple interface to the INTERBUS system does not require any form of local intelligence,associated microprocessors or software. With that, a basic requirement for a simple sensor/actuatornetwork, the complete hardware single chip solution for simple I/O devices, is fulfilled. For the connectionof more complex devices which are capable of communication, a microprocessor is required besides theprotocol chip to run the protocol software. The microprocessor system simultaneously handles theapplication program of the device.
b) Slave Software
The PCP protocol software required to implement parameter communication is available as an ANSI-Csource code. The PCP software implements the ISO/OSI Protocol Layers 2 b and 7 with PMS services.The software package includes extensive documentation of the source code as well as a description of thePMS structure and services. Extensive porting seminars and individual porting support as well as otherservices are offered.
c) Master Implementation
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
There are several ways to interface masters. On the one hand, the master protocol chip (IPMS) can beused directly. On the other hand, it is possible to use a fully implemented master interface board as thebasis. Besides the master protocol chip, this interface board contains a microcontroller system with thecomplete firmware routines needed to carry out the master functionality including the extensive systemdiagnostics. It is integrated as a piggy-back board in user-specific hardware concepts. Communication withthis interface board takes place through a defined and simply structured memory interface. The use of thismaster interface board greatly reduces development costs and time. It also guarantees that the masterboards have full system compatibility.
d) Tools
For a quick implementation of interface prototypes, an evaluation board with the complete hardware andsoftware for simple I/O interfaces and also communication-capable systems based on PMS services areoffered. Amongst other things, the evaluation board hardware consists of the INTERBUS protocol chip, an8051 microcontroller system with all peripherals, as well as a dual-port memory used as an interface to theapplication processor. The software on the board encompasses the complete PCP protocol software aswell as an exemplary connection of the communications interface to the application processes.
A comparable evaluation board for the quick implementation of master prototypes is offered in connectionwith the master interface board.
An interactive communications monitor is available for developing and testing INTERBUS interfaces. Thismonitor software runs under MS-DOS and works together with an INTERBUS PC board. To becomefamiliar with the communication structures, a simulation mode can be chosen, in which communicationmessages can be exchanged with a virtual device without requiring further hardware.
The support services outlined are supplemented by carrying out various training seminars, providingsample circuit diagrams and further services, such as checking circuits and technical support.
5.1 Test and Certification
Many end users e.g. from the automotive industry have been convinced by the system conformity anduniversality from the start. The transmission protocol and the transmission physics have remainedunaltered since their introduction to the market in 1987! Devices from the initial phase are still working onthe bus today - that convinces the user and gives him the necessary confidence to make investments. Theprotocol conformance of the sensor/actuator bus on the other hand has made a major contribution to theinternational proliferation and creation of the bus standard.
To give the end-user additional security, a quality test was introduced: the independent conformance andinteroperability test. A steady protocol ensures secure investments but does not guarantee that a devicewill function correctly and without disturbances in the open fieldbus network. For this reason theINTERBUS Club has introduced a testing and certification procedure to provide the device manufacturerswith the necessary proof of quality for their products.
The device manufacturer can offer his customers proof of independently tested quality and thus gains anedge over his competitors. He also has the guarantee that his device functions without disturbances in theINTERBUS network.
End users and OEMs have recognized this important advantage and ask for the INTERBUS certificate intheir invitations to tender.
In this way it was possible for an industrial standard to become established and gain more and moreacceptance internationally. There are independent testing centers in Germany (Fraunhofer Institute forInformation and Data Processing IITB), in Austria (TU Vienna, Field Bus Competency Center CEF-FBK), inSwitzerland (Swiss Electrotechnical Association SEV) and it is also planned to set up a testing laboratory inthe USA.
At present there are approx. 100 certified product types from various manufacturers. In no other fieldbussystem have such numbers of devices been certified! This demonstrates the true nature of openarchitechture and system security as provided by INTERBUS.
5.2 The INTERBUS Club
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
The INTERBUS Club is a worldwide group of interested manufacturers and users of INTERBUS products,who have set themselves the goal of supporting the international processing of the communications systemto network INTERBUS field devices, for the benefit of the user (extract from the rules of the INTERBUS-SClub e. V., Germany). Today, the club has a worldwide net of 10 INTERBUS Club organizations, whichoperate independently of one another in the key markets of the globe.
Their success depends on the commitment and enthusiasm of now well over 400 members, from A forASA in Germany, to Z for Zaklady Automatyki in Poland. They are in pursuit of the common goal: to furtherexpand the position of INTERBUS as leader of the world market. To this end, the clubs have setthemselves the following tasks: Promotion of...
- Innovation
- Standardization
- Quality
- Share of the market
...of INTERBUS.
· Innovation by forming powerful user groups which promote INTERBUS technologies. Recentexamples of this are the INTERBUS Loop and particularly the new INTERBUS technology, "OpenControl", which is causing a worldwide sensation at the moment.
· Standardization by creating profiles for the most important device types and by sendingrepresentatives to the most important international standardization committees. The INTERBUSprotocol was given the number DIN 19 258 in 1993. The European standard, EN 50 254 is inpreparation.
· Quality assurance by introducing an efficient procedure for the certification of devices. Thisprocedure consists of committees which lay down the testing standards, independent institutes whichcarry out the tests, and a committee which takes the decisions as to granting certificates. (Thesemethods for certification help to ensure that devices from various manufacturers can function side byside in an INTERBUS network, without interference or disturbance, thus being a decisive factor forsystem quality).
· Share of the market by carrying out joint marketing actions on all the important international markets.The member enterprises show their presence on the market here in various ways with the support ofthe INTERBUS Club (trade shows, advertising, Internet etc.) and thus present their products jointly.
5.2.1 Your Way to the INTERBUS Club
The INTERBUS clubs have offices which offer their members and interested public numerous services.Many of them are aimed at providing information for manufacturers and users of INTERBUS. Well-knownexamples of this: this brochure, the international supplier index on CD-ROM, the Internet homepage(http://www.interbusclub.com) not forgetting the regional club news letters, specialist literature, profiledescriptions, specifications etc., or extremely practical aids such as the support of users in the search forINTERBUS-compatible devices. On top of this, the clubs offer manufacturers of INTERBUS in particularnumerous services. They range from technical support to sales promotion. The service catalog of yournearest INTERBUS Club can provide detailed information.
5.3 INTERBUS Club International
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com
In addition to the original INTERBUS Club in Germany, there are now 10 INTERBUS clubs worldwide.
The international INTERBUS clubs are not "divisions". They are independent INTERBUS clubs, which arelooked after and run independently. They precisely know the market in their own country, understand thelocal mentality and can undertake activities and strategic actions according to the market.
Despite this independence, all international INTERBUS clubs work together to exchange experience andmake use of the synergy effect.
They all have the same goal: They are the interface between the user and the manufacturer, providesupport when it comes to INTERBUS and help to increase the popularity of the fieldbus INTERBUS withinthe international market.
[Top] [Prev]
Copyright © 1997, INTERBUS CLUB. All rights reserved.
C
ourte
sy o
f Ste
ven
Eng
inee
ring,
Inc.
� 2
30 R
yan
Way
, Sou
th S
an F
ranc
isco
, CA
, 940
80-6
370 �
Mai
n O
ffice
: (65
0) 5
88-9
200 �
Out
side
Loc
al A
rea:
(800
) 258
-920
0 �
ww
w.s
teve
neng
inee
ring.
com