Search results

This paper aims to describe the results of an investigation into the techniques used to design factory control systems in the body‐in‐white section of car‐manufacturing plants in Germany, the UK and the USA.

Research was conducted through a set of semi‐structured interviews with the individuals responsible for planning control system architectures in a number of companies world‐wide.

The challenges faced by the users of industrial control systems, such as the need to conduct changes quickly, accurately and without errors, are identified. Each organisation participating in this study was seen to use a company‐specific standard to bring commonality to systems and to improve the ease of developing, maintaining and modifying their control systems. Similar software structures were seen to be in use in many of the companies participating in this survey, though in some cases differing attitudes to the use of the same tools were observed.

This work captures, documents and reviews industrial practice in a structured manner, providing an insight into the factors affecting the selection of control system technology by industrial users, and serves as a starting‐point for researchers wishing to investigate the relative importance to industrial practitioners.

Existing work on industrial programming practice is extended by detailing specific software structures used in manufacturing operations in the car industry.

This paper aims to propose a model for the provision of EtherNet/IP device‐specific function blocks by discrete industry device vendors and to outline how multi‐vendor network environments can benefit from the use of function block programming to encapsulate code for configuring communication, diagnostics and visualisation tools.

The approach makes use of function blocks to facilitate simpler use of the EtherNet/IP protocol. The EtherNet/IP messaging mechanisms are described, along with the methodology for configuring communication for both time‐critical and non‐time‐critical messaging, including device‐specific status and diagnostic data. The same approach is utilised for communication to visualisation systems.

Validation of the model was found to make data transfer between controller and device easier and faster, owing to a reduction in the number of operations a programmer was required to implement. Implementation time was found to be just 6.25 per cent of that needed to achieve the same functionality without the use of function blocks.

The use of function blocks to describe EtherNet/IP communication was tested with a commercial product in an application environment, and subsequently adopted by multiple vendors. A reduction in technical support was noted owing to the use of identical interfaces for multiple device instances. With complete device functionality described and readily available to the end‐user, greater device functionality is utilised and more often may otherwise not have been implemented for time, cost, or complexity reasons.

In the discrete industry, it is uncommon for device vendors to provide device‐specific function blocks describing network communication interfaces and functionality, since they reside in the controller, not the device. This research presents a novel method that provides a consistent, yet flexible approach for the configuration of EtherNet/IP communication for differing devices from multiple vendors within a controller.