INTERBUS System Technology Basics INTERBUS

First steps with INTERBUS System Technology Basics INTERBUS

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 will also get the know-how required for a first general decision on the fieldbus topic and especially on INTERBUS.

Any questions, suggestions, help, etc. Send mail to: WebMaster [email protected] - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 [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

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com 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

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 1. Preface to the INTERBUS Club

Serial field bus technology is increasingly meeting with international acceptance in all areas of industrial

applications, 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 industrial control 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 of INTERBUS-compatible devices with a technical overview of the functionality, efficiency, delimitations, and applications of INTERBUS. In the opening section it deals with the trend within open automation technology, further explains the INTERBUS protocol, points out possible areas of application and gives tips on the implementation of the devices.

All in all, what we are presenting you, the technically interested user or manufacturer, is a comprehensive document 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 and plants are under development. The enormous competitive and cost pressure which weighs heavily on all areas of production and process enginee-ring, necessitates the exploitation of existing rationalization potentials. From this point of view, the conventional parallel wiring of sensors and actuators in a machine or system turns out to be inflexible and a serious cost and time factor. A remedy for this is the serial networking 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. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

At the same time, the increasing globalization of the markets is making new demands on systems and mechanical engineers regarding the solutions in control technology. The world of automation technology is no longer homogenous but is in stead dominated by national or regional market leaders. Machine and plant constructors operating internationally have to take these conditions into account. At the same time, being competitive on the international market means that an automation solution must be standardized and able to be used worldwide without major alterations. The result of this has been the demand for open modular control architectures which can be accepted worldwide or, with slight modifications, adapted to national

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 preferences.

Future automation systems will therefore be based on flexible control systems, the performance and function of which can be adapted to changing requirements without interrupting the system. Under this aspect, changing the control system or the control system manufacturer should not affect the other automation components. One precondition for these open control architectures, which result in considerable cost savings over the complete lifetime of the machine or system, is standardization in all areas 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 the past. These trends enable users to interchange and freely select their control system. In terms of control hardware 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 a standardized connection between the different makes of control systems and the wide range of process peripheral equipment currently available on the market. The solution to this problem is the implementation of serial bus systems which, apart from offering all the above-mentioned advantages, can also effect a

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com standardization of the link between control system and peripheral equipment.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 To meet the future challenges of an seamless flow of information and the support of open and flexible control architectures in automation engineering already mentioned, bus systems in the field of sensors/actuators must meet two essential requirements. The bus system must provide the user with a universal solution for his automation task. For applications in open 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 control technology while using the existing process peripheral equipment, is often lacking. Each system represented on today's market is only supported by one of the major PLC manufacturers. The German PROFIBUS fieldbus is supported by the PLC manufacturer Siemens, DeviceNet by Allen-Bradley and FIP by Telemecanique. The availability of the system and its efficiency depend on the PLC manufacturer's

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com interest 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 reestablish customer 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 to discrete sensors and actuators), many systems must rely on a variety of different partial solutions due to a lack of technical capability. By marketing products under a single name, manufacturers attempt to convey the impression of a "pseudo universality". In reality, however, users are suddenly confronted with two, three or even four completely different systems in their plants. This becomes evident for example in the case of PROFIBUS with the variants, "FMS", "DP", "DP+" and "PA", or, in the case of Allen-Bradley, with the network structure, Data Highway, Control Net and Device Net. This multitude of variants increases time and costs for training, maintenance, stockkeeping, tools etc. and does not exactly enhance reliability of the plants. 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 the lack of suitability of the implemented transmission protocols for use in the field of sensors and actuators. In order to create a seamless applicable protocol, from the control level through to discrete sensors and actuators, the protocol must be designed with the very special requirements of the "critical" area of sensor and 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 technical characteristics, is particularly suitable for use in the field of industrial sensors and actuators, and laid out for consistent networking from the control level down to the last limit switch. INTERBUS is not sponsored by one major PLC manufacturer, but is supported by an independent network supplier as well as currently more than 700 device manufacturers with new technical developments and products. Thus, INTERBUS can be considered as the "NOVELNET" of industrial communications and is therefore an essential

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 component 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 In Germany, following the wishes of the users, the key functions of INTERBUS were standardized by the DKE (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 services needed for process data communication. The specifications for parameter data communication are also generally 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 this standard will be taken by the fall 1997, in a single-phase procedure in the countries belonging to the CENELEC. EN 50 254 is identical to DIN E 19 258 and will supersede it after publishing. The following figure shows the identical document structure of DIN E 19 258 and EN 50 254. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 [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 the hierarchical course of the functional levels of a plant or factory.

In particular, the area of industrial sensors/actuators forms a very specific and individual requirement profile. However, due to the traditional method of viewing situations "top-down", hardly any fieldbus solutions have so far taken this into account.

The areas where control systems and computers are networked, and those of sensors and actuators cannot be regarded as a homogenous field, as their demands on a communication network are completely different. PLCs, NCs, robot controllers and computers etc., are networked to each other on the process level. The exchange of data and programs ranging from several Kbytes to Mbytes per device is demand or event-driven. This data represents unique information, the transmission of which must be secured via appropriate acknowledgement and repetition mechanisms of the network protocol. The data is usually transferred not only to a system situated on the next hierarchy level (host computer), but also between devices on the same level. This is the classic "peer to peer" communication found in all higher-level hierarchies. In the field of sensors/actuators, however, two additional properties are required, which are irrelevant in all other areas of automation levels. First, the network should be capable of carrying out time-constant scanning of process data. Second, the data is reduced so drastically per device that the efficiency 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 and the control systems or process control computers. Owing to this definition, this area comprises very simple devices such as limit switches and contactors, which are part of the traditional I/O level of PLCs, as well as complex devices such as drive controllers and operating devices. These "intelligent" devices increasingly implement the distribution of classic central PLC functions. A network for sensors/actuators must not only be suited to simple but also to complex devices. Therefore, when determining the demands made on the - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com network, it is absolutely crucial to take into consideration the demands of all components interoperating with these devices and not just a single device class, such as drive components or sensors. Only an integral approach prevents the creation of such heterogeneous single networks within the field of sensors/actuators and control engineering overall. This concept of a uniform network which is oriented towards 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 shows that the data to be transmitted can be divided into two basic types: first, the I/O or process data and second, the messages or parameters. Both data types are fundamentally different, whereby an understanding of their differing demands on a communication system is the elementary basis for the realization 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 for contactors and valves, for example, are process data, but also setpoints and actual values of drive control systems. Process data per terminal device is not highly complex and usually comprises no more than a few bits. Because of the concept of decentralization, endeavors have been made to gather data and make it accessible 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 amount of 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 1 or 2 bits of information, a fact which must be taken into account when selecting a system. Process data has the character of cyclic information which must be continually updated via the network. Furthermore, in order to realize automatic control tasks, it is necessary to have constant and calculable scanning intervals

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 for setpoints and actual values. In this context, this is also referred to as the demand of a deterministic and time-equidistant data transmission. Due to the small amount of information per network device, there usually is no local data preprocessing in the area of process data. Therefore, the transmission times must be directly oriented towards the process time constants. Taking the capability of modern control systems into account and the necessary machine cycle times, the updating of process data contained in a network must be carried out within a period of 1 - 5 ms. It is likely that this time requirement will move in the direction of its lower limit in the foreseeable future.

Process data is usually uniquely identified by its address or the terminal device it represents. An additional description of this data for transmission purposes is therefore not necessary. The mapping of this data to the 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 on demand and is therefore nonrecurrent. Transmission of parameter information requires special security and acknowledgement mechanisms. The complexity of a parameter block in the area of sensors/ actuators ranges 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 transmission can generally be regarded as uncritical. Depending on the type of device and extent of the network, the requirements range between a few 100 ms and several minutes. Because intelligent data sources can receive and send a wide range of information, a para-meter block is not identified by its device address alone. In fact, its transmission requires additional, descriptive information which is included with the aid of so-called communication services.

The fundamental data types mentioned can be used on all sensor/actuator devices. Simple devices are generally only represented by process data; "intelligent" field devices, on the other hand, e.g. drives, supply or require both data types. In this way a drive is initialized and parameterized via the parameter information, while, for example, the setpoint and actual value for frequency and rotational speed are typical process data which put very high demands on the network dynamics to realize control and closed-loop control functions. However, even in the area of "simple" devices, the trend toward parameterization can increasingly be seen. Serial networking provides the opportunity to parameterize even a simple sensor via the network and these possibilities will be used more and more in the future. In addition to the different communication requirements of the process data and the parameter information mentioned, general requirements of a sensor/actuator network can be formulated. A decisive aspect when designing such a bus system is that the operation of the system should be tailored to the knowledge level of the staff on - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com hand in the application environment. Staff working with networks in the area of sensors/actuators are not generally EDP specialists. Therefore, the network installation and maintenance must be simple and easy to understand. Stochastic or priority-controlled access procedures require time-consuming performance and utilization analyses of the network to determine worst-case access times and must therefore be ruled out for a sensor/actuator network. A clear master-slave structure ensures deterministic access times as well as the simple planning and design of the network. It must also be possible to service the network without the need for special tools and time-consuming training. The system must be equipped with such comprehensive diagnostic functions that even a service technician unfamiliar with the system is able to detect defective system parts. Defective components must be easy to replace without the need for any further adjustments to the device. Manual adjustment of device addresses, necessary in many network concepts, 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 the use of simple transmission media be ensured, which means easy installation, and the achievement of high electromagnetic compatibility. At first glance this requirement appears to contradict the demand for short transmission times. In order to fulfill both demands, the protocol of the sensor/ actuator bus must optimally utilize the implemented transmission rate, i.e. display a high rate of efficiency. It is therefore of no advantage when a network has a data transmission speed of, for example, 12 Mbits. It is not the transmission speed which is decisive but the data throughput achieved during transmission; this is also called protocol efficiency.

The demands made on the size of a network vary enormously depending on the application. The distance between the devices may be just a few meters within a machine or several hundred meters in the areas of installation, materials handling and warehousing.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 When devices from different manufacturers are to be operated in an open network, a simple and, above all, non-proprietary diagnostic tool in the form of a computer-aided user interface is of particular importance. As already demonstrated, the demands made on the communication system by the two basic device classes or data types of the sensor/actuator systems differ completely. On the one hand, I/O transfer is imperative in order to realize the real-time demands, while on the other, a message transmission mechanism, enabling para-meterization of devices, is also desirable. However, these conflicting demands must not lead to a single application area being served by two different networks, one for real-time I/O data transfer and one for parameterization of devices. This would mean that those devices requiring both data types, such as drives, would have to be equipped with two network interfaces, an entirely unacceptable situation 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 this question, we must first compare two basic methods of message transmission. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com The classic, message-oriented transmission method is based on a logical point-to-point connection between two devices. In order to transmit cyclic process data, a central master prompts each sensor in succession with a message to send its input data. The prompt is acknowledged each time by the response of the sensor. Transmission of data to the actuators is carried out in the same manner. In this case, the control system sends a message with output data to an actuator. The actuator, in turn, acknowledges this message with a response. In this procedure a complete transmission protocol is executed between the central master and a slave, whereby a message with no user data contents is always transmitted via the network. Besides the actual user data, a transmission protocol or message frame must also transmit a large amount of overhead data (address, command, data back-up etc.). The fact that, typically, very little information per device is transmitted in the area of the sensors/actuators and that the protocol mechanism is very time consuming, means that transmission of cyclic process data is very inefficient. However, this is not 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 considerably increased. The message-oriented transmission method is ideal for the transmission of complex, non-cyclic parameter blocks, but is not suited to the cyclic transmission of short process data.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

The second basic transmission method is the so-called summation-frame protocol. This method combines the data of all sensors and actuators of a network into one message. This message is sent to all devices simultaneously. The transmission overhead occurs only once. Combining the information of all networked devices into one message frame expands the useful data block considerably. The efficiency of this protocol increases dynamically with the number of networked devices, which, as we know, is typically very high in the area of the sensors/actuators. The summation-frame protocol is optimally suited to the transmission of cyclic process data. However, adding complex parameter information to the frame message would lead to a considerable lengthening of the frame and slow down runtime performance for short process data. In addition, the non-cyclic character of the parameter data is incompatible with the cyclic procedure of the summation-frame method. By principle, the summation-frame method guarantees the demand for determinable and fixed scan intervals and its high efficiency provides a combination of a low data transmission rate and a high data throughput.

The following short example demonstrates the major differences in efficiency between the communication - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com protocol and the summation-frame protocol with regard to process data transmission. This example is based on a system with 32 networked devices, each of which represents 8 bit process data. A typical message-oriented transmission method requires an overhead of up to 200 bits in order to update this 8 bit process data. This means that efficiency of the system is approx. 4 %. In other words, only 4 % of the total transmission 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, constant overhead, 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 current response time requirements, transmission rates of several Mbits must be used. These rates constitute the limits 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, the message-oriented method has no more solutions to offer, if the demands on network response times continue to increase and the trend towards decentralization continues, i.e. a network comprises more and more devices with less and less information. This becomes painfully clear when networking single sensors.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

Today, modern semiconductor technologies enable cost-effective connection of even single sensors and actuators to bus systems. However, because of their protocol characteristics, it is not possible to make such a connection and retain the necessary data throughput with fieldbus solutions based on the message-oriented procedure. Even an increase of the baud rate, which often is already too high at several Mbits, has no further effect. The "pure" sensor interface systems, which arose as an alternative, only cover small areas of the automation solution due to distance and data quantity limitations. Today, in some cases a "marriage of convenience" between the message-based protocol and the sensor interface system is promoted as as a compromise solution. However, the result is not a solution which satisfies the user's demands, but another variant in the fieldbus assortment. The summation-frame method, however, offers full data throughput without system interruption, even for discrete devices.

This comparison of transmission methods shows that neither of the two methods really satisfies the central demand for a universal network for cyclic I/O data and non-cyclic parameter information. The solution to

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com this problem lies in a synthesis of the positive characteristics of both procedures, which is a feature of the INTERBUS system.

3.0.3 INTERBUS, the Sensor/Actuator Bus

INTERBUS not only complies with the universally accepted sensor/actuator profile, but also satisfies customer 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 the interface to the higher-level control or bus system. The INTERBUS topology is a ring system, i.e., all devices are actively connected to a closed-loop transmission path. On the main ring leading off from the master, subring systems can be formed to structure the entire system. These connections are carried out using special components called bus terminal modules. A subsystem can be of a local character, referred to as the local bus, which is typically used to create local I/O clusters within a switch cabinet. On the other hand, it can also be a system which couples remote devices over long distances. A distinctive feature of the INTERBUS system in comparison to other ring systems is the fact that both the forward and return data lines are contained in one cable which runs through every single device. This produces the physical appearance of a line or tree structure. A common form of the physical layer of the INTERBUS system is based on the RS 485 standard. This is a differential voltage interface, which uses twisted-pair leads for the transmission 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, a distance of 400 m between two devices is possible due to the RS 485 point-to-point transmission. The integrated repeater function in each device enables an overall extension of the INTERBUS system of up to 13 km. For ease of operation, the number of INTERBUS devices is limited to a maximum of 512.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 3.0.3.1 INTERBUS Topology The point-to-point structure of the INTERBUS system and its division into main and subring systems is ideal for the implementation of completely different physical transmission technologies and, in particular, the future-oriented fiber optic technology. The bus system is equipped in such a way that any part of the system can be converted from copper technology to fiber optic technology, to infrared data transmission systems or any other media using standard converters available on the market. Similarly, fiber optic-capable devices can be implemented to set up whole networks based on this interference-immune and installation-friendly technology. There is no need for the expensive repeater converters as required by multidrop structures. The ring structure gives the system two decisive advantages. First, and in contrast to a line structure, the ring permits data to be sent and received simultaneously (full duplex). Second the system's self-diagnostic feature can be considerably improved using a ring system. In the case of bus-type systems (trunk line) with multidrop device connection, all devices are quasi passively coupled to the bus. However, the passiveness 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 a short-circuit in the bus line, or if the line is short-circuited at any other point outside the device, no further communication is possible at all in such a system. If this type of fault occurs in bus-type systems, it is not possible to detect the location of the fault using the automatic diagnostic functions of the network. A ring system with active device coupling on the other hand provides a segmentation of the entire complex into electrically independent subsystems by its very nature. Thus, in the case of the active failure of a device, a short-circuit or the disconnection of a bus line, communication is only interrupted from the location of the fault onward. The network management functions of the bus enable localization of the fault, so that the - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com service technician knows immediately where repairs are needed. The same applies to sporadic transmission faults e.g., caused by electromagnetic interference sources or faulty cabling. In the line system, this also accidentally destroys any number of messages. In the case of such an undifferentiated interruption in transmission, it is not possible to localize the fault. This results in repeated, and often lengthy interruptions in the operation. The active device coupling of the INTERBUS system, which monitors every single transmission path, enables unambiguous fault location even in this case. It is precisely this fault location feature which is crucial when it comes to minimizing system downtimes. However, before a system standstill occurs, INTERBUS allows preventive error locating by means of a statistical evaluation of the system's transmission quality. This error frequency evaluation allows, for example, the early detection of component failures due to normal wear, and prevention of a production standstill. With these possibilities for the complete analysis of error type and error location, the INTERBUS system assumes an outstanding position among fieldbuses. As a result of a uniform start up and diag-nostic concept for all INTERBUS devices - consisting of diagnostic functions on the INTERBUS devices, front panel diagnostics on the controller boards and an oper-ator interface based on that of the PC - system diagnostics becomes practicable for the user.

The fact that local subring systems can be set up in the INTERBUS network also permits a connection and disconnection of devices without interference. The coupling elements between the bus segments can be controlled by the central bus master and permit the subsystem to be enabled and disabled. It is therefore possible to manipulate the subsystem without affecting the rest of the system in any way.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

The data is not allocated to individual devices by assigning a bus address to individual devices, as is necessary in other systems, but, due to the active device coupling, via the physical position of the device within 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 manually during installation or maintenance are often underestimated. In addition to this automatic physical addressing of the bus devices, optional logical addressing of individual bus devices can be carried out at a central point in the bus master by simply creating an address allocation list. This makes the device addresses used by the application program independent of their physical position in the system. It also enables problem-free removal and addition of devices in the ring without the need to change existing address 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. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

Layer 1 is the Physical Layer. It is here that the time conditions such as baud rate, permissible jitter and so on, 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 INTERBUS takes into account the support of both data types occurring in sensor/actuator technology - the cyclic process 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 with Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 which the cyclic data transport between the remote devices takes place. INTERBUS is based on the summation-frame procedure, which is assigned to the class of collision-free TDMA transmission procedures (TDMA: time division multiple access). This means that every device is allocated a time slot suited to its function, which makes it simple to calculate the transmission time as the sum of all the time slots. Additional time slots can be defined for connection-mode data blocks "on demand". In this way, data blocks of several Mbytes can be transmitted with INTERBUS, without altering the cyclically short scanning reference for the process data types. The independence of these two data types from one another is decisive for the performance capability of the INTERBUS protocol and the ability to realize closed-loop control tasks via this protocol. In combination with each other, these protocol characteristics permit the realization of a seamless network covering control systems, intelligent field devices, and single sensors and actuators. In addition, the summation-frame procedure guarantees that the process image is consistent between all devices, since all input data stems from the same scan time and all output data from the devices is received at the same time. A further advantage of INTERBUS is the high rate of efficiency of the protocol, i.e. that the additional amount of data (overhead) needed to save and synchronize data is small in comparison to the amount of user data. In contrast to other bus protocols, the physical transmission rate can be kept low. This is reflected directly in the costs for components and cables as well as in the improved EMC behavior. On the other hand, however, this also shows the unique potential that INTERBUS can offer when the transmission rate is increased. It is not necessary in this case to compensate for the protocol over-head by increasing the transmission rate in order to obtain an adequate throughput 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 register structure. Every INTERBUS device joins the ring via a register, the length of which is determined by the amount of process data points of the device. By coupling all the devices together, a ring is created, the length and structure of which corresponds exactly to the configuration of the user data field in the summation-frame message.The process output data for peripheral equipment is placed in the output buffer of the master according to the physical order of the connected output devices. A transmission cycle begins with a data sequence. This data sequence contains the loopback word on the transmission side, followed by the output data. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

During data output, the return flow of process information is simultaneously entered into the input buffer of the 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 check sequence (FCS) serves to check the user data transferred to the data sequence. This data save is carried out using a check sum procedure with a CRC polynome in acc. with CCITT. Due to the point-to-point

structure, the error checking mechanism always takes place between two neighboring devices. Controlled

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 by the frame check sequence, the exchange and comparison of the CRC polynomial remainder is then carried out simultaneously for all devices, so that one single transmission overhead is generated by the CR check, which is effective for the whole system. The check sum status in the remaining 16 bits of the FCS is first transmitted. This check sum status is used by every device to report both transmission errors of its own which it recognizes to the next device, and to recognize errors from the previous device. If the check sum status shows no recognized transmission errors, the data in the registers is released to the application. New input data to be transmitted continues to be requested by the application. In addition to the data cycle for the transmission of user data as described above, an identification cycle is also defined in the Data Link Layer of INTERBUS. This cycle acts as the bus management. Each bus device has a Layer 2 identification code, which gives information as to the type of device and its range of user data. The independent configuration of the bus system is carried out by a sequence of identification cycles which the bus master initiates in order to read in the identification of the remote devices. Using the identification code read in, the summation-frame configuration for the data cycle can be established. Layer 1 of INTERBUS functions with an asynchronous start/stop procedure. One header, which contains additional information such as frame end identification, function code and message type, is added to 8 information bits and transmitted as a data message. During breaks in transmission in which there is no output of user data from the master, the regular data flow is filled up with status messages. They do not contain any Layer 2 data and serve mainly to guarantee permanent activity on the transmission medium. If this data activity is interrupted for a period of > than 20 ms, it is interpreted by all the devices as an interruption in the system. As a result, the devices are switched to a defined and safe reset status, i.e. all devices are switched to the safe status within a very short time in the event of an interruption in the system or failure of the controller board.

3.0.6 The User Interface

The protocol and topology characteristics of the INTERBUS system described above ensure for the first time an innovative integration of the demand for cyclic I/O data transport and non-cyclic message transport in a single system, while at the same time taking into account, and fulfilling, the demands of the entire field of 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. In order to create a user-approved solution, the INTERBUS application interface has also been divided, in accordance with the two data types. INTERBUS responds directly to the user demand for process mapping of simple, transparent process data. A cyclic program in the bus master continuously updates the process data and makes it available to the user in the control system in the form of an I/O process image. That is to say, 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 have

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com a drastic effect on the real-time characteristics of the process data protocol. For freely programmable computers, as for example PCs, the process data in the interface storage (DPM) can be accessed directly using drive functions or standardized software interfaces (DDE, OPC, Open Control). When accessing process data, the user of the INTERBUS system will not notice any difference between serial cabling and the traditional parallel cabling. Users are not required to familiarize themselves with complex communication structures.

3.0.6.1 PMS Services

Open communication can only be achieved with standardized, universal communication services that meet the demands of all devices and applications. Such standardized agreements already exist in the area of factory 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 it can be implemented regardless of the device or application. Based on the structure of the MMS, a compatible subset of the defined communication services has now been created for the INTERBUS system and is called PMS (Peripherals Message Specification).

The about 25 PMS services permit simple communication with intelligent process devices. Services are available, amongst other things, for establishing and monitoring communication links (context management), reading and writing variables or parameters (for example: read/write), as well as starting up programs (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 operating in the INTERBUS network can carry out services on the PMS level (server), as well as transmitting services autonomously (client).

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

With programmable logic controllers, access to the PMS communication services from the application programs is not carried out via parallel I/Os as with process data, but is realized via so-called function blocks (data handling blocks). In addition to this, the communication services can be predefined during the project planning of the system and then need only be activated as saved function blocks via bit commands when the sytem is put into operation. This simple interface saves the user from making up complicated data handling routines to exchange communication data, and reduces the use of communication services to the handling of logic operations.

The standardized use of the universal PMS in the INTERBUS network not only permits direct access to process data, but also provides the desired communication link between simple sensors/actuators and intelligent field devices and control systems. This hybrid procedure, with its easy memory access to process data, permits program structures already available in parallel cabling to be transferred directly into serial networks. Thus, users can even respond to intelligent network devices via process data alone. In this manner, for example, drive controllers on INTERBUS can exchange setpoint and actual values for the

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com rotational speed via the process data channel. This means that the rotational speed setpoint can still be specified 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 MAP networks, INTERBUS can be integrated into a universal network concept, from the factory level through the process and cell level to the sensors/actuators, thereby providing, for example, an ideal supplement to the Ethernet standards of the higher commmunication levels which are quite common today.

[Top] [Prev] [Next]

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 [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 the INTERBUS system characteristics described above. One of the main demands during the development of the 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 how INTERBUS meets these demands.

In the previous illustration, the sample system is first shown with the usual parallel cabling. A conveyor belt is driven by a drive, which is PLC-controlled and supplied with setpoint values. Binary limit switches are also scanned in the system.

The parallel lines for binary information transmission and analog transmission paths, which are particularly susceptible to faults, are not required in the serial system. All signals are transmitted to the control system via the INTERBUS network. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

The programming tables show that exactly the same program can be used for both conventional and serial cabling. The rotational speed setpoint information, which is analog data with conventional cabling, is now transmitted to the drive as a process data item. The transmission of complex parameters is just as simple as writing a program for process data. The signal interface previously described is now used to activate the action blocks.

It is possible, for example, to define the complete initialization of the drive as a closed "action". Using the convenient INTERBUS configuration tool CMD (Configuration, Monitoring and Diagnostics), which will be described in more detail later, the initialization data is transferred from a PC via the universal V.24 interface, loaded onto the INTERBUS controller board and combined into a single "action block". Single control bits are then allocated to these "actions" in the so-called signal interface to the PLC. All network

activities and communication services linked to the initialization of the drive can then be triggered by setting

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 a single bit from the PLC program and controlled by interrogating a further bit. Thus, complex communication is reduced to the PLC user's usual handling of binary logics. The user only carries out the actual function of device parameterization; the background communication services are automatically 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 PLC architectures must also offer the user a concept for uniform and, above all, manufacturer-independent system handling and diagnostics. The openness of modern bus systems usually stops short of the configuration and diagnostics of the connected control systems and devices. Bus devices are becoming increasingly complex and many now require special operation and diagnostic tools in order to make practical use of all their functions. Nowadays, virtually all PLC and device manufacturers offer their own software packages, which means it is extremely difficult for the user to integrate single components into a network or start up the network as a whole. This plight is particularly obvious when it comes to diagnostics or service, when you cannot afford any delays or operational problems. The user of a bus system is often confronted with a multitude of different diagnostic concepts and aids which make it more difficult to - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com eliminate the error quickly.

A start up and diagnostic software, CMD (Configuration Monitoring Diagnostics) was developed for INTERBUS, the main features of which lie in the independence from the control system used and the flexibility 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 becomes necessary, whether in the project planning phase, at start up, for operational monitoring, or in the evaluation of diagnostic data. In addition, it is possible to program small process data preprocessing routines directly on the controller board, using the IEC 1131 programming language, "Function Block Diagram". The user can define the INTERBUS system configuration in the project planning phase with the CMD software. Program addresses, via which the control program can later access the remote I/Os, can be allocated in CMD. Parameterization and operation of the INTERBUS controller board are carried out here 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 getting used to different software tools is no longer necessary. All INTERBUS project data is stored centrally under CMD and made available to all groups involved in the operation of the system. CMD can run under the operating systems Windows 3.1 / 3.11, Windows 95, and Windows NT 4.0 on any standard PC. Coupling to the control system used by the user or to the INTERBUS controller board integrated in this system is realized via a standardized RS 232 interface within the INTERBUS network. In this way, it is guaranteed that various controller boards and makes of control systems can be operated by just one software tool.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 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 in the form of an electronic data sheet. This can be read in and processed directly by the CMD software. The INTERBUS supplier index (CD-ROM) already contains a multitude of such descriptions, as well as a complete overview of INTERBUS-compatible devices on the market. In the case of new developments, the user 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 further functions or new add-on programs from any manufacturer at all times. Thus, if a manufacturer supplies a particular device with a operational program, the user can easily integrate this program directly into INTERBUS CMD. In order to standardize, for example, the operation and selection of particular groups of devices, e.g., frequency inverters and drives, the manufacturers of drives have joined together in the INTERBUS Club to form a user group, and have agreed on profiles according to which these devices can be addressed. A consequence of this has been a joint add-on program within the framework of CMD. The benefit to the user: a uniform environment for the operation and parameterization of frequency inverters and drives from various manufacturers. Such a concept can of course also be realized for other device groups.

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 fail and call for "a downward extension". The standardized INTERBUS protocol enables the amount of data per device 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 be continued 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 the transmission method in this area to suit the application conditions.

This transmission technique is known as INTERBUS Loop. INTERBUS Loop links the individual devices such as sensors, actuators but also, for example, drives and encoders to a ring, with a simple two-wire unshielded cable. The Physical Layer, which has now been adapted to the application, carries the data information and the 24 V power supply simultaneously to up to 64 sensors by means of one cable with two conductors.

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com The data is transmitted in the form of load independent current signals, which considerably increases the immunity to interference compared to the voltage signals normally used. Thus, INTERBUS Loop is so immune to interference that even in an industrial environment, it can be operated fault-free without shielding! 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 INTERBUS Loop, together with all other INTERBUS products, can be used on a common bus. Also, several INTERBUS Loop segments per INTERBUS remote bus can be interconnected. If, for example, there are more than 64 INTERBUS Loop-capable components to be integrated, the user simply adds a new bus terminal module. Additional measures such as the installation of special power units do not have to be taken into account and paid for over again by the user. Besides the conversion to the new bus physics, the INTERBUS 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 the INTERBUS Loop, the data ring has been opened to form an actual, physical ring. Thus, it is possible to transmit 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 any application which may occur, whether near or not.

There are two areas of application for INTERBUS Loop: on the one hand it connects individual devices directly in the system, so the bus connection must be carried out in IP 65. On the other hand, the INTERBUS Loop cable is routed into the switching cabinet and connects the components there. This enables not only contactors and miniature circuit breakers to be wired more easily, but also indication and control devices such as switches, keys or signal lamps, which are equipped with a Loop chip.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 The protocol compatibility of INTERBUS Loop means it can be used with all other INTERBUS devices. All INTERBUS-compatible control systems can therefore be implemented as a master. Problem-free expansion of an existing INTERBUS system is also possible. INTERBUS Loop devices are fully functional INTERBUS devices, which still have all the advantages of the INTERBUS system. No sensor functions are excluded from INTERBUS Loop. It even permits integration of complex sensors e.g., those delivering numerous measurement values which can sometimes be continuously modified. Right from the start, it is thus not restricted to digital signals.

Because the connection of INTERBUS Loop to a larger INTERBUS system does not require any protocol conversion, there is no need for costly gateways, and data scanning is perfectly synchronized throughout the system. The high data throughput unsurpassed by other manufacturers also remains with the INTERBUS Loop, since it also functions at 500 kbit/s as effectively as usual. The features mentioned so far distinguish 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 a standardized, simple and seamless bus system.

Using the newly developed connection technique (QUICKON), the bus cable can be connected quickly and

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com reliably without tools. The connection can also be disconnected as often as desired and is thus not dependent on a questionable self-healing of the cable. The fact that the cables can be easily disconnected from 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 simply adapting the transmission method, and not affecting the standard INTERBUS protocol, clearly demonstrates the performance capabilities of the INTERBUS protocol and its provision for extension. In order to provide a complete solution for an automation task, it is not only necessary to network field devices 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 of fulfilling these requirements, as well as being capable of the afore-mentioned cyclic, time-equidistant scanning of I/O data, the INTERBUS protocol is also optionally capable of non-cyclic, demand-oriented communication with larger amounts of data. This parameter channel, also called PCP (Peripherals Communication Protocol), together with the cyclic I/O protocol, provides the complete solution to an automation task. The following example of an application in the automotive industry clearly demonstrates this performance capability. This application was discussed in working groups comprising automotive manufacturers, 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 of the PLC, which are provided to control the system, comprise 12 welding controllers, 8 robot controllers, as well as four valve maintolds, a wrenching controller, 10 control cabinets with approx. 300 discrete I/Os, two servo drives, two operator stations and a bolt welding facility. The PLC has to exchange cyclic I/O data with all 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 a higher-level PC. The task includes that each of the 12 welding controllers must be supplied with 100 kbyte Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 programs, while the programs for the robot controllers can even be as large as 2 Mbytes. The third requirement 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.

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 physical segments. The coupling between these individual segments is carried out by "System Couplers"- a special feature of the INTERBUS system. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

This system coupler has simultaneous master and slave functions for the INTERBUS network and can even provide a third interface to the control system. In this manner, data can be exchanged between two physical bus segments by avoiding the control system. The configuration can be carried out assuming a logical seamless system.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

Furthermore, it is possible, e.g. in the robot controller, to receive data directly from the PLC or to supply I/O data from a secondary robot controller to the network. The illustrated topology permits the following system characteristics. The cyclic data exchange between PLC and I/O level is carried out in a cycle time of < 6 ms. Parallel to this cyclic data transfer, for example, the programs of all 12 welding controllers can be simultaneously transferred in 3 minutes. When the programs alone can be transferred to only one robot, it is even possible to transfer up to 2 Mbytes in approx. 3 minutes. These program down-loading times are approximately the same as those achieved by field bus systems, such as PROFIBUS, which are specially designed to handle the task of transferring large data blocks. The great advantage of the INTERBUS system is that this program downloading does not affect the cyclic scanning of I/O data in any way, i.e.,

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com even if 2 Mbyte programs are loaded to the robot, the limit switch is still scanned at a fixed time interval of 6 ms. This characteristic cannot be ensured by any other bus system on the market. The peripheral equipment at the level below the robot even has a scan time of 1 ms, whereby, as already shown, it is possible 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 are already putting it to the practical test, in actual plants.

The characteristics of the INTERBUS system described clearly show the performance capability and the performance reserves of the protocol, which ensure the future reliability and stability of INTERBUS. The attempts of other systems to accommodate the growing demand of the market by continually changing the protocol, the baud rate and the transmission methods, has led to the creation of an assortment of incompatible partial solutions. When realizing an automation task with, e.g., PROFIBUS, this can soon lead to 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. In the 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 provides the overall solution for automation tasks, from networking the control systems down to the "last" single sensor and actuator. The communication tasks range from program storage and machine data acquisition through typical "real time control tasks" to complete control loops. For the system user, this ultimately means reliability and real savings, in terms of time, material, stock and personnel, during the entire life cycle of the machine or plant.

3.0.11 Interoperation with Device Profiles

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 To achieve an interoperation of devices from various manufacturers across a common network, it is necessary to standardize the communication characteristics of these devices. This alone, however, does not ensure error-free operation of these devices with one another and arbitrary replacement of these devices by those from different manufacturers. A truly open and flexible system requires, over and above the standardization of communications and networking, also conventions on device functionality. This is made clear by a motion control example.

Two drives from different manufacturers are networked via a common bus. Both drives are supplied with a rotational speed setpoint. In this case 4000 revolutions. Because of its internal definitions, drive 1 interprets the transmitted data as a 16 bit integer value. However, drive 2 interprets the same data as a 12 bit integer value. The result of transmitting the same data to different devices in the first case is a rate of 4000 revolutions; in the second case the drive rotates in reverse at 96 revolutions. The resulting problem lies in the non-standardization of the data structures and device functions. INTERBUS solves this problem by using common definitions worked out by groups of manufacturers. These device definitions are also known as 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 and users. They have therefore been defined keeping close to the practise and reflect the requirements from specifie 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 functions of their devices in a profile known as the DRIVECOM Motion Control Profile. The practical result of this standardization is that a DRIVECOM profile compliant drive from manufacturer A can be exchanged for a drive from manufacturer B and it is guaranteed that the same control program will work with the new drive in 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 bus systems (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 user - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com of such devices can thus be sure that these certified devices will function together on the same network without problems. The INTERBUS profiles guarantee the reliable operation of different devices from various manufacturers on the network, otherwise known as "interoperability". Just like the INTERBUS software, INTERBUS-CMD, the profiles are important elements for an open and flexible control system technology. 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. The INTERBUS protocol specification has remained stable or been expanded in a compatible manner since then. Today's devices can still be used without problems with devices of the first generation. This stability was a major requirement for the fact that well over 700 manufacturers of devices offer more than 1000 compatible INTERBUS devices on the market. Potential users of the INTERBUS system have the choice of a large number of tried and tested INTERBUS-compatible devices. In the field of control systems, it is controller 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 on over 80% of the PLCs on the market. Apart from these programmable logic controllers, INTERBUS can also be connected to open computing systems such as VMEbus systems and of course IBM-compatible PCs. controller boards to other control systems are currently under development. In the field of distributed I/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 flow controllers, measuring instruments, identification systems, pneumatic and hydraulic components, to a multitude of distributed I/O devices from diverse manufacturers. With such distributed I/O modules, all process signals, whether of a binary or analog nature, can be connected to INTERBUS. The entire

spectrum of manufacturers of INTERBUS-compatible devices is listed in the INTERBUS supplier index, Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 which is available both as a printed document and as an electronic directory on CD. This broad support for the INTERBUS system, especially evident among small to medium-sized companies, offers the user a wide choice of products and manufacturers.

[Top] [Prev] [Next]

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 [Top] [Prev] [Next]

3.1 Open Architecture in the PLC Environment using INTERBUS

With ever increasing internationalization, shorter planning and development phases, stricter customer provisions 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 offer their components on a standardized platform and open a wide spectrum of products to the users. To this end, INTERBUS offers a neutral fieldbus platform and, at the same time, goes a long way toward standardization and application-oriented functionality.

Open planning with INTERBUS means:

with the integration of INTERBUS and the system, the control and industrial PC technology becomes an innovative system solution for all major makes of control systems, which together have a market share of over 80%. The basis is formed by the Generation 4 INTERBUS controller boards. They form the uniform peripheral access to the control systems.

Simple "Plug and Play" technology combined with extensive diagnostic functions which check the entire system autonomously and report interferences. Parameterization and operation of the functions is identical for all controller boards. The software tool, IBS CMD (Configuration Monitoring Diagnostics), which can be run under Windows, serves as a bus configurator in the project planning phase. Bus configuration, address allocation for inputs and outputs, documentation of the same and parameterization of intelligent devices in the network is carried out via an interactive graphic environment. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

The pure substitution of parallel input and output boards to create bus-capable components is extended with INTERBUS automated systems by the additional integration in an intelligent bus system with data preprocessing functions. Simply parameterize using IBS CMD in acc. with IEC 1131 and a control-independent coprocessor is available to your system.

With the INTERBUS data preprocessing, the functional machine layer provides the interface to the application program. The system function is programmed on the control side and sent to the controller board via the input/output layer. The machine-relevant data which is functionally connected with the components in the system is projected onto the host controller board (e.g., fast switching off of an output

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 port for positioning).

At its simplest, this would be interconnections between sensors and actuators which are wired via the INTERBUS system. Further, parameter data from intelligent field devices such as frequency inverters or robot controllers, right up to control information such as interlocking of the mechanical processes are transmitted. The advantages of the extensive possibilities of parameterization pay off when there is a change from one system to another control system or to an industrial PC. It is now only the sequence of machines that remains to be adapted to the new environment.

The system-specific functions, the INTERBUS parameterization, operation and diagnostics, as well as parameterization of the intelligent devices, are carried out directly. Changing a control system does not mean 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 has proven worthwhile in a variety of applications. Plants of a leading automotive manufacturer have been equipped with a different control technique, for example. Parameterization of the existing INTERBUS system, including the preprocessing functions, documentation and cabling have remained the same and are simply coupled with the altered busmaster. The same parameterization, start up and operation of the entire system help to secure investments and react flexibly to the market. The extensive range of functions of the INTERBUS controller boards supports innovative applications so as to be one step ahead in the market.

3.2 Open Control

Large international users, e.g., GM, Chrysler or VW, have recognized the disadvantages of the manufacturer-specific control systems dominating the market today and favor systems based on open PC architecture and an open standardized fieldbus system for the future. In order to place particular emphasis on their demands, the OMAC paper (Open Modular Architecture for Controls) was formulated by General Motors and Chrysler. Open modular automation systems based on PC architectures thus, for the first time, give the user the opportunity to escape from the dependence on control systems manufacturers still dominating the market. He can now select the most suitable product for his application with the best possible application know-how from a wide range of components from various manufacturers. With the aim of fulfilling the demands of the users and creating an open automation standard for the future, the Open Control User Group was founded by 17 companies on 8 March, 1996, with the INTERBUS-S Club e.V. as patron.

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com Within the Open Control User Group, work groups for marketing and technology were set up. The work group for technology is involved in the definition of standardized interfaces between the components of a complete automation solution. These components are, for example, visualization and control software, as well as runtime systems, configuration and programming tools, as well as peripheral components connected via a fieldbus. Other major components are the open PC architecture and the operating system used with it.

These standards were formulated in the technology work group meetings and are now available as a first specification. 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 within milliseconds.

2. Interfaces between the runtime systems and the superimposed application (e.g., visualization), where data 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 the variable definitions and variable parameters.

In order to put this interface definition into practise, the CALL interface (Control Application Link Layer) was formulated by the Open Control User Group. The CALL specification is divided parallel to the interfaces described above into the CALL-P (periphery), CALL-R (runtime) and CALL-E (engineering).

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

With the aid of the CALL interface definition of Open Control, it is now possible to create automation solutions individually with products from various manufacturers, without experiencing problems with the interface. The common data base, for example, enables a variable which has been defined using manufacturer 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 to errors, will disappear.

The Open Control User Group has, from the start, aimed to base its interface definition on existing standards. In this way, tools available now can also work with tools based on Open Control. It is thus possible, with OLE/DCOM technology, common in Windows NT (used by Open Control), to make data available for other applications. In this way, production piece numbers and the quality of the products can easily 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). At - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com present, the OPC Foundation is made up of over 140 mainly American member companies. By using the OPC definition, there is a guarantee that even applications that only come up to the OPC standard can be integrated into Open Control applications. In addition to the definitions made in OPC, CALL-P is specified by Open Control, which means that the peripherals connected via the fieldbus are incorporated in the complete automation process.

As a result of the pragmatic approach in the Open Control User Group and consistent contact with the users, results were achieved very quickly. On the basis of this first specification, prototypes are already being 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 80 international companies in only a few months, proves that the Open Control User Group is on the right path with its work. This and the active participation of the users makes it obvious that the PC is defining the control 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 market worldwide. Each of these manufacturers concentrates on a particular geographic area and offers a self-contained solution. For this reason, machine and plant engineers, who have to react flexibly to the wishes of their clients, must equip their machines that have the same functions with different automation solutions. Thus, the machine that is sold in Germany is equipped with a German make of control system and that which is sold in the US with an American one. This results in a considerable increase in the costs of the system conception, since project planning, programming, training, stock keeping, service, and so on

vary from manufacturer to manufacturer and therefore, have to be counted twice. Open Control offers a Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 way out of this situation, as it is based on open PC architecture, with a world market volume of over 250 billion US $ and several hundred suppliers. This means that Open Control-based automation solutions can be individually equipped with components as desired by the clients. The reliable interaction of all components is guaranteed by the Open Control CALL specification and the certified interfaces of the various suppliers based on this. The control hardware is thus no longer the solely decisive part of the automation solution, but can, like all other components, be exchanged in almost any way. The efficiency of the control system will therefore no longer be solely dependent on the innovative energy 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 field means that lower prices and better product quality can be guaranteed in the long run. On balance, it can be said that the future of the automation solution via Open Control definitions has already become reality. It will therefore supersede modern automation technology, which still consists of a PLC and an industrial PC for 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 the standard hardware platform worldwide. Nowadays, PC systems are used a million times a day and have proven themselves in a variety of tasks. The large share in the market of PC systems, independent of any special field, has resulted in a multitude of different components. This wide spectrum of technology available worldwide enables the configuration and use of systems which can be scaled in a flexible manner and an exemplary cost effectiveness. In conjunction with the operating system Windows, the PC is nowadays also the basis for software for all tasks and applications to which thousands have access. Due to its graphic design, Windows is the ideal platform for tasks involving visualization and further provides always 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. INTERBUS technology, specially developed for this area in industrial automation, has influenced this development from the start and proven itself as a stable protocol on the market since 1987. INTERBUS, with more than 1.2

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com million 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 fact that it is strictly aimed at the needs of the users and applications have steadily expanded the fields in which INTERBUS systems can be employed. The efficiency of INTERBUS technology already enables, for example, 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 transmit data blocks of up to several 100 kbytes and simultaneously to read the highly dynamic sensor and actuator technology with their demands of millisecond scan cycles. In this way, both control information and administrative messages e.g., programs or parameter records, can be downloaded at the same time without influencing each other.

3. Programming system based on the international standard IEC 1131-3.

In the case of classical control systems from traditional suppliers, the programming system is always directly linked to this specific control series of the manufacturer. Parallel to the development of the PLCs themselves, this has in the past led to an immense diversity of programming methods and dialects. At the same time, the size of an application program grew with the increasing degree of automation in 10 years by about a hundred times. In order to master the complexity of the modern control systems from an economic stand point, the standard IEC 1131 "Programmable Controller" was formulated under the patronage of the "International Electrotechnical Commission". This standard is not merely another new programming language, but unites the experience which has been collected in millions of applications in PLC programming and partly described in national standards e.g., France (Grafcet), USA, (NEMA ICS 3

304), and Germany (DIN 40719, 19239 and VDI 2880). Based on the standardized structures of a modern Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 automation 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 the other hand, two textual languages, the classic Instruction List (IL) and the modern Structured Text (ST). The availability of this comprehensive standard reduces not only the cost of producing and updating the control software itself but also the costs for training the programming and service staff. Open Control unites these established standards: PC architecture, INTERBUS technology and the IEC 1131 programming model to form a common platform for a forward-looking and innovative automation system. The broad base provided by Open Control does justice to the ever growing demands of the international market, with its shorter and shorter innovation cycles and aggressive price movements.

The software structure illustrated in figure shows the design, which is modular in two respects. Depending on the application, we distinguish between engineering and runtime components, whereby these too have a modular structure. The engineering part contains the components for programming, system configuration and system diagnostics, components for the production of visualization graphics and further components such as robot control systems, or CNC controllers, depending on the system. All these components work under a common engineering environment with common project administration and exchange their data via a common data base. The open interface architecture means that new components can be integrated at any time or existing ones exchanged. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

[Top] [Prev] [Next]

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 [Top] [Prev]

4. INTERBUS in Action

In 1997, INTERBUS will be used in over 120000 systems with almost 1.5 million networked field devices. It is thus the most widely spread fieldbus standard worldwide. The fields of application for the INTERBUS system include all areas of industrial automation technology. It is used in production engineering, in mechanical engineering, in warehousing and logistics systems, in the food, timber and paper industries, in industrial process systems including hazardous areas, and also in systems which require fault-tolerant systems with a very high degree of availability. The list of INTERBUS users includes a great number of large well-known enterprises throughout the world. In the European automotive industry, about 80% of all body shop and welding plants are realized with INTERBUS systems. All large international automotive manufacturers rely on INTERBUS; in North, Central and South America, in Asia and in all countries in - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com Europe. 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 high degree of system availability and a drastic reduction in idling.

The universality results in a standardized bus topology, since the entire automation task is realized wholly

with INTERBUS, without other bus systems or patched together partial solutions. Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 5. The Way to INTERBUS- compatible Devices 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 to make the introduction of INTERBUS technology as easy as possible for these manufacturers, the INTERBUS Support Center was established as a service group to support them with the integration of INTERBUS. The INTERBUS Support Center today offers a graded concept of implementation tools, support services, protocol chips and complete interfaces. This comprehensive range of solutions allows device manufacturers to implement INTERBUS interfaces with prior knowledge of costs. - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com

a) Slave Hardware

A basic requirement for an acceptable network concept is the existence of highly integrated circuits for protocol handling. For this reason, protocol chips for slave and master interfaces have been developed for the INTERBUS system. These protocol chips are freely available and are offered with comprehensive documentation. The protocol chip for slave interfacing implements the complete cyclical I/O protocol and is a 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 optimally supported. As figure 20 shows, only a few external components are required in addition to the protocol chip. 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/actuator network, the complete hardware single chip solution for simple I/O devices, is fulfilled. For the connection of more complex devices which are capable of communication, a microprocessor is required besides the protocol chip to run the protocol software. The microprocessor system simultaneously handles the application program of the device.

b) Slave Software

The PCP protocol software required to implement parameter communication is available as an ANSI-C source 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 the PMS structure and services. Extensive porting seminars and individual porting support as well as other services are offered.

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 c) Master Implementation There are several ways to interface masters. On the one hand, the master protocol chip (IPMS) can be used directly. On the other hand, it is possible to use a fully implemented master interface board as the basis. Besides the master protocol chip, this interface board contains a microcontroller system with the complete firmware routines needed to carry out the master functionality including the extensive system diagnostics. It is integrated as a piggy-back board in user-specific hardware concepts. Communication with this interface board takes place through a defined and simply structured memory interface. The use of this master interface board greatly reduces development costs and time. It also guarantees that the master boards have full system compatibility.

d) Tools

For a quick implementation of interface prototypes, an evaluation board with the complete hardware and software for simple I/O interfaces and also communication-capable systems based on PMS services are offered. Amongst other things, the evaluation board hardware consists of the INTERBUS protocol chip, an 8051 microcontroller system with all peripherals, as well as a dual-port memory used as an interface to the application processor. The software on the board encompasses the complete PCP protocol software as well 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 connection with the master interface board.

An interactive communications monitor is available for developing and testing INTERBUS interfaces. This monitor software runs under MS-DOS and works together with an INTERBUS PC board. To become familiar with the communication structures, a simulation mode can be chosen, in which communication messages can be exchanged with a virtual device without requiring further hardware.

The support services outlined are supplemented by carrying out various training seminars, providing sample 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 and universality from the start. The transmission protocol and the transmission physics have remained

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com unaltered since their introduction to the market in 1987! Devices from the initial phase are still working on the bus today - that convinces the user and gives him the necessary confidence to make investments. The protocol conformance of the sensor/actuator bus on the other hand has made a major contribution to the international proliferation and creation of the bus standard.

To give the end-user additional security, a quality test was introduced: the independent conformance and interoperability test. A steady protocol ensures secure investments but does not guarantee that a device will function correctly and without disturbances in the open fieldbus network. For this reason the INTERBUS Club has introduced a testing and certification procedure to provide the device manufacturers with the necessary proof of quality for their products.

The device manufacturer can offer his customers proof of independently tested quality and thus gains an edge over his competitors. He also has the guarantee that his device functions without disturbances in the INTERBUS network.

End users and OEMs have recognized this important advantage and ask for the INTERBUS certificate in their invitations to tender.

In this way it was possible for an industrial standard to become established and gain more and more acceptance internationally. There are independent testing centers in Germany (Fraunhofer Institute for Information and Data Processing IITB), in Austria (TU Vienna, Field Bus Competency Center CEF-FBK), in Switzerland (Swiss Electrotechnical Association SEV) and it is also planned to set up a testing laboratory in the USA.

At present there are approx. 100 certified product types from various manufacturers. In no other fieldbus

system have such numbers of devices been certified! This demonstrates the true nature of open Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080 architechture and system security as provided by INTERBUS.

5.2 The INTERBUS Club 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 system to network INTERBUS field devices, for the benefit of the user (extract from the rules of the INTERBUS-S Club e. V., Germany). Today, the club has a worldwide net of 10 INTERBUS Club organizations, which operate 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 for ASA in Germany, to Z for Zaklady Automatyki in Poland. They are in pursuit of the common goal: to further expand the position of INTERBUS as leader of the world market. To this end, the clubs have set themselves the following tasks: Promotion of...

- Innovation

- Standardization

- Quality

- Share of the market

...of INTERBUS. ·Innovation by forming powerful user groups which promote INTERBUS technologies. Recent examples of this are the INTERBUS Loop and particularly the new INTERBUS technology, "Open Control", which is causing a worldwide sensation at the moment. ·Standardization by creating profiles for the most important device types and by sending representatives to the most important international standardization committees. The INTERBUS protocol was given the number DIN 19 258 in 1993. The European standard, EN 50 254 is in preparation. Quality assurance by introducing an efficient procedure for the certification of devices. This ·procedure consists of committees which lay down the testing standards, independent institutes which carry out the tests, and a committee which takes the decisions as to granting certificates. (These methods for certification help to ensure that devices from various manufacturers can function side by

- 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com side in an INTERBUS network, without interference or disturbance, thus being a decisive factor for system 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 of the 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-known examples 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, profile descriptions, specifications etc., or extremely practical aids such as the support of users in the search for INTERBUS-compatible devices. On top of this, the clubs offer manufacturers of INTERBUS in particular numerous services. They range from technical support to sales promotion. The service catalog of your nearest INTERBUS Club can provide detailed information.

5.3 INTERBUS Club International

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080

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 are looked after and run independently. They precisely know the market in their own country, understand the local mentality and can undertake activities and strategic actions according to the market.

Despite this independence, all international INTERBUS clubs work together to exchange experience and make use of the synergy effect.

They all have the same goal: They are the interface between the user and the manufacturer, provide support when it comes to INTERBUS and help to increase the popularity of the fieldbus INTERBUS within - 6370 Ÿ Main Office: (650) 58 8 9200 Outside Local Area: (800) 25 www.stevenengineering.com the international market.

[Top] [Prev]

Courtesy of Steven Engineering, Inc. Ÿ 230 Ryan Way, South San Francisco, CA, 94080