No abstract

PurposeThis paper sets out to highlight the problem associated with the development of fieldbus diagnostics in a multi‐vendor environment and to propose a solution based on diagnostic function blocks (FB).Design/methodology/approachThe work focuses on the “master‐slave” communication model in a PROFIBUS fieldbus system, where three different vendor solutions are investigated.FindingsAlthough the fieldbus standards specify the type and format of the diagnostics data, the extent, location and sequence of diagnostics data within a controller are entirely vendor‐dependent. The outcome from this work defines a framework for representing the diagnostics data in the context of a special function block.Originality/valueThis research work defines a novel unified framework for representing the fieldbus diagnostics data using FB for multi‐vendor solutions in a PROFIBUS environment.

The ever increasing use of networked field devices in manufacturing environments brings about new challenges for diagnosis and supervision of these devices. Manufacturing has become more multivendor, multiple fieldbus orientated and consequently diagnosis of a variety of geographically wide spread fieldbuses has become a necessity.The research work proposes the development of a single diagnostics device for local and remote access to diagnostics data from multiple fieldbusses. The PROFInet standard is one of the networks covered by this research work, and this paper details the issues surrounding the retrieval of diagnostic information through a PROFInet interface on this device.

No abstract

PurposeTo emphasise the need for remote fieldbus diagnostics and to show a technical solution based on industry standard approaches.Design/methodology/approachThe design and approach takes a Profibus fieldbus, as an example candidate, and captures the diagnostic data using an OPC model and then uses a Java RMI object broker to develop/support the remote end clients.FindingsThe findings show, by an implementation example, that it is possible to implement remote diagnostics for a fieldbus network, without interfering with the operation of the network. The findings also highlight the need for security in such a solution.Research limitations/implicationsThe implementation example is rather cumbersome, but the paper suggests that all the hardware and software could be implemented on a single embedded processor in a single box. The security issues are flagged as a possible limitation, but solution approaches are briefly suggested.Practical implicationsThe paper highlights the lack of standardisation around fieldbus diagnostics. Even for the same fieldbus type, different manufacturers will use different diagnostic protocols and codes. This paper suggests a practical implementation, where the diagnostic codes can be interpreted a fixed stage and presented to an end client in a consistent manner.Originality/valueThis work is based on a two year original research project. The solution makes heavy use of industry standard protocols but the work is original.