Program Design

In a large profinet-io system, a key point of concern is the effective use of the communi-cation channel. With multiple levels of control between io-controllers and io-devices with

subordinate I/O systems, update times can be affected by the size of the transfer areas.

The larger the transfer area, the higher the bandwidth demand. Furthermore, the amount of decentralization in control functionalities as one moves down the hierarchy can also determine how much data needs to be transferred between io-devices and controllers.

The decisions that can help in alleviating these concerns and how they apply to the im-plementation in Chapter 4 are addressed in the rest of this section. The total bandwidth used at the io-device is the sum of the bandwidth of the transfer areas and the bandwidth of the subordinate I/O system (if there is one) [60].

3.3.1 Standard Program

In keeping up with the objectives of this thesis, an RTU only captures remote process data (its own local I/O) for the controller, which sends command signals in return. For communicating recipes and other product information between controllers, Siemens PLCs have manufacturer-specific program blocks for implementing this and are dis-cussed in [61]. Similarly, there are manufacturer-specific systems that enable the moni-toring of device diagnostics in a profinet-io network, but these are not the focus of the final implementation.

For the two-device system on which this thesis is based, it is enough that the length of transfer areas be the same as the number of physical I/O addresses in the io-device. In this way, the controller always has real-time access to the states of the RTU I/Os, con-sidering that PLCs can be regarded as state machines and assuming that their complete state is determined by I/O values. Hence, on the controller side, function blocks encap-sulating the functionalities in the RTU can be programmed directly in the controller by using the I/O addresses of the transfer areas. On the RTU side, the standard program only needs to be a simple program mapping local I/O to the transfer area outputs, whose states are available to the controller’s transfer area inputs in real-time.

For larger systems possibly with thousands of remote I/O points, it may be more appro-priate to keep the function blocks on the RTU side and populate the transfer areas with just as much data as needed to represent specific states of the RTU. These specific states can then be used for initiating action in the RTU. More importantly, implementing multiple hierarchies of control allows for the creation of a truly decentralized control sys-tem as no single controller will have to deal with network traffic from all the other devices.

In this manner, the computing and networking resources of the system are better utilized as more pre-processing takes place in the RTUs and there is less bandwidth demand on every communication link in the network. A possible implementation of such a decentral-ized system for the whole Festo network is presented in Appendix E.

3.3.2 Safety Program

Best practice demands a complete separation between safety-related parts and non-safety-related parts of a control system. The siemens STEP 7 programming environment readily provides such a framework for the control engineer: the standard program and the safety program are separate logical units. The operating system manages the exe-cution of both programs in every scan cycle. Safety programs on different devices com-municate with one another using the profiSafe profile. This ensures logical separation in the exchange of safety signals between the controller and any number of io-devices us-ing the same physical medium. The functional safety part of the implemented solution involved monitoring the perimeter (safety zone) of the production area using laser scan-ners connected to safety I/O modules in the controller.

It must be said that in a system with distributed devices the appropriate fail-safe response often depends on the nature of the operation that each device directly interfaces with.

For example, in a station with a normally open pneumatic gripper for moving material during production, activating a safety relay to disconnect the source of pneumatic pres-sure leads to dropping the material mid-operation. This itself might be a source of hazard to the equipment or humans in the environment. Hence, this thesis favours a decentral-ized safety approach: the safety logic in the controller responds appropriately to the sit-uation in its own domain and sends a safety signal to RTUs in the network, each pro-grammed to respond appropriately in accordance with that part of the system. Another common concern regarding such fail-safe system is the amount of effort required to re-start the system after a failure. Business and profitability concerns suggest that the best fail-safe response for all parts of the system is one which causes the least downtime for the production process.

Finally, the control engineer must be aware of the mechanisms by which data can be exchanged between the safety-related and non-safety-related parts of the control sys-tem. In the Siemens STEP 7 environment used for this thesis, the rules governing such exchange within the controller and RTU are presented in Tables 3.1 and 3.2. This thesis proposes using safety data blocks (F-DBs) to exchange safety information between the safety programs in the network. Safety data will also be available for evaluation in the standard program as Table 2 shows that the standard user program has read (R) access to data in an F-DB. The safety programs in the controller and any number of RTUs form a safety network that allows safety data to pass from the top to the bottom of the control hierarchy.

Table 2: Data exchange by data block (DB) [62]

From the standard pro-gram

From the safety program

R access W access R access W access Tag from

DB

permit-ted

permitted A tag from the DB can be R-accessed or W-accessed

Tag from F-DB

permit-ted

not permit-ted

permitted permitted

Bit memory permit-ted

permitted Bit memory can be R-accessed or W-ac-cessed