10/03/03 - Information - An Analyser for AS–Interface
The analyser presented in this paper closes a diagnostic gap. For the first time users have access to an easy and precise analysis of AS–Interface networks. This tool reads the complete data exchange on the bus, analyses it and provides a status report for the network. Network errors or malfunctions of a single slave can be easily identified and corrected by the user. Weaknesses are highlighted for preventative maintenance.
A tool, which up to now did not exist due to the simplicity of the system, is now available: An analyser for AS–Interface networks. It registers and checks all message traffic as a "listener" on the network. The analyser checks the functions of the network in complete detail to document them and to identify possible errors. The benefit to the user is increased even more if the master supplies only limited diagnostic information in addition to the AS–Interface data.
The AS–Interface works digitally and is integrated into the network as a passive component (Fig. 1). Normally it is installed temporarily to check a network. As is the case with all AS–Interface components it is interoperable, meaning it can also be used in a network with products from different manufacturers. The extracted data can be transmitted via an RS232-interface to any PC, where it can be analysed. The recording and final analysis settings can be adjusted using software supplied with the analyser.
The analyser can be used either in a "standard mode" or in an "expert / trace mode". In the standard mode the messages are analysed mostly in a statistical manner. The results are very easy to extract, are directly available and give an exhaustive overview of the functioning and possible errors of the network (Fig. 2, left column).
In the expert mode the entire telegram traffic (or selected parts) is stored in the analyser, then transmitted to a PC offline where it can be analysed (Fig. 2, right column). This mode, which is aimed at specialists, allows an even more detailed analysis of the events on the network.
Sections 1 and 2 will describe the functions of the analyser, while section 3 points out its advantages from the point of view of the user.
The standard mode is the most commonly used mode. The analyser is connected to both the network and the PC (normally a laptop) for analysis. The results are displayed live on the screen. This mode enables even a user who only has basic knowledge of AS–Interface to quickly get an excellent overview of the network.
When the program is started the "overview" tab is selected by default, as displayed in figure 1. The status of all slaves is shown with three colored bars. Green indicates the slave is communicating normally (including permitted message repetitions), a yellow bar tells the user that this slave should be checked and red indicates a major fault and that the slave must be checked. The display is refreshed once a second (for details see below).
Selecting the "Data" tab displays the current data of all slaves. This is also refreshed once a second. Thus the entire periphery data is available for the check of an application; it does not have to be extracted from the PLC (the host) (figure 3).
The standard mode also makes it possible to check the network configuration (figure 4). After each offline phase of the network the master reads the permanently stored configuration data of each slave. The analyser transmits this to the PC. The user thus has the capability to document the entire configuration, which makes the analyser another important tool for the check and acceptance of an application.
By switching to the "Advanced Statistics" tab the user gets the number of repeated messages for each slave as well as the number of master calls to each slave. Both are continually read from the network, totalled and transmitted to the PC each second (figure 5). This process runs as long as the analyser is connected to the network and is only stopped for the trace and loading process in the expert mode.
In erroneous networks the increase of errors can thus be monitored. This enables immediate checks and corrections. Oftentimes an increase in repetitions can immediately be attributed to disturbing influences from the environment. The user can also check the long-term stability of a network from the aggregated value for the entire time of the measurement.
In the expert mode the messages transmitted on the network are stored in the analyser, either entirely or in selected parts only. A computer does the analysing process after the data has been stored. The separation of recording or "tracing" and the analysis enables a detailed analysis of each single message, which requires more calculating capacity than the online analysis in the standard mode. This also makes it possible to choose additional options for storing and displaying the information. Using this mode requires more in-depth knowledge of AS–Interface than the standard mode, thus the name "expert mode".
This function stores all messages transmitted on the network starting after the "trace" command. The storage capacity of the analyser is sufficient for data exchange for a duration of about 37 seconds, which is equivalent to 256,000 master and slave telegrams. They form the so-called "frames" which can later be queried in complete detail. Figure 6 shows a small part of the display.
A trigger option can be activated for the complete recording, which stepped several times triggers the trace process. The storage starts if a specified trigger event occurs, such as an erroneous telegram (figure 7).
If necessary two additional filter levels can be set. After the first filter has been triggered the analyser waits for a second (or third) trigger event before starting to record the communication.
If this option is chosen the analyser reads all messages into its memory. Once the memory is full the oldest data is continually deleted as new messages are read. When the trigger event occurs the recording process is stopped so that all the data from before the trigger event is still stored and can be analysed.
This function is useful for the analysis of errors that are hard to detect or only occur from time to time. The trigger can either be set from the outside through the trigger input or as a result of a certain set of telegrams.
Finally, the trigger option can control other tools via a trigger output. If this output is linked to the trace trigger a storing oscilloscope can be triggered. Thus the exact analog signal that led to the error can be displayed.
By activating a filter option special message sequences on the network can be selected for storage. Messages that are not relevant for analysis can be left out. The recording process can then be reduced to single slaves, specific master calls or slave answers, or to good or erroneous telegrams. This filter is constructed similarly to the trigger option in figure 7. The filter allows for a great reduction of the number of stored telegrams. The recording time can thus be significantly increased, e.g. for long-term analysis. It can also make the analysis more clear and straightforward.
The filter option can also be used during the offline analysis, in a similar manner in order to narrow down an unknown situation.
The AS–Interface Analyser is a universal tool and its different functions can be used for diverse tasks in the network or application. The most important cases are described below (fig. 8). The first four can be done in the standard mode. The expert mode must be used for the rest.
Message errors or malfunctioning slaves cause messages to be repeated on AS–Interface. The number of these repetitions is an index of the stability of a single slave and the entire network. The analyser calculates and grades this this number.
Since telegram repetitions are generally provided for in the AS–Interface system the user has cause for concern only if their number exceeds a certain value. In the analysis for the cases "green", "yellow", and "red" in the graphical display of the "overview" tab (figure 9) the number of repetitions is related to the total number of telegrams read in one second.
Slaves marked with a green bar are functioning normally, meaning repetitions occur rarely if at all. They correct spontaneous message errors, which affect neither the functioning of the system nor its availability.
The yellow bars generally mean the same, but the number of repetitions indicates that the network or individual slaves communicate in a rather cumbersome way. The user, who may not even realise this condition in many masters, should search for the cause of these errors and eliminate them in a preventive maintenance measure. This way the threat of an unexpected stop of his application can be decreased.
There can be various reasons for this sort of behaviour: Errors during the installation (e.g. earth connection on the AS–Interface cable, exceeding the 100 m length limit, usage of unsuitable cables, loose connections, temporary power shut down, etc.), slave errors (e.g. impedance and symmetry errors through manufacturing or conception faults in slaves which have not been certified), or EMC-disturbances (in the case of extreme demands or incorrect installation) or other errors.
AS–Interface networks can often work even in the case of heavy disturbances. In those cases the number of repetitions may become so high that the cycle time may be prolonged, especially in cases when several slaves are concerned. The threat of an unintended "Config Error" - a temporary or permanent slave error - increases; many user programs tend to react to this with a shutdown of the application, even if the network could pick up the slave concerned automatically. Such slaves are indicated by a red bar.
The Config Error is thus the really important error case one must be able to detect and identify. Possible causes are the above mentioned if they occur frequently. Furthermore some slaves signal a malfunction (e.g. missing auxiliary power, over-current at an actuator, etc.) by cutting the communication. Even a temporary low voltage can lead to a Config Error if the slave is not properly included in the network. These must be eliminated, except for those cases, such as applications with changing network components, in which it is within the scope of an application.
In the protected mode of the system a grey bar indicates a slave that has been detected but not activated by the master because it has not been included in the configuration.
The display is refreshed once a second. Selecting the tab "Overview Hold Time" the user can choose if "yellow" and "red" should be switched back to "green" after a certain time span, if the slave works normally again (auto recover). By using a short time span for switching back the results of corrective measures can be immediately checked. On the other hand a user would not choose any setting back if he wants to prove even short-term disturbances within in a long-term analysis. A single heavy disturbance, which in the cause of the recording time has once led to "yellow" or "red", will therefore remain documented within the tab "Overview".
The numerical presentation of the error statistics under "Advanced Statistics" shows more detailed information than the division in three coloured displays. Here the analyser will show the number of message repetitions for each slave within the entire diagnosis time span, as well as the number of master calls (figure 5).
If using the online mode the increase of error times can be directly observed and attributed to its causes. The success of corrections on the network or a drift of the network stability during longer time spans can thus be measured more quantitatively than in the display of figure 9. Corrective measures are directly supported.
The results of the "advanced statistics" are continued until a reset. The error counter shows the total number of repetitions of messages since it was switched on or since a chosen reset. Looking at the "advanced statistics" one can see whether there was only one single problem for a "yellow" or "red"-marked slave or whether there are permanent faults. One can clearly see this when comparing figure 5 and 9 which have been recorded in the same run: All faults have happened within a short time span only.
AS–Interface has been designed as an extremely simple system. The configuration of a network can be done by the master itself and is usually then considered done. This does the job in many cases, but can cause difficulty if the configuration of the network at one specific instant has to be viewed. This can be the case after it is first installed or when checking intended or unintended changes. The analyser makes it possible to document the condition at one specific point in time. This has been shown in figure 4 for the I/O configuration of an AS–Interface network, which can be documented independently of the master and host and does not have to be read from the PLC.
This configuration can be printed in detail together with the contents of the "overview" and "advanced statistics" tabs. Thus, the user can document not only the configuration but also the condition of the network. This is an ideal means for the inspection and approval of a new application.
Besides the statistical analysis in the standard mode the user can also choose an analysis of single data frames in the expert mode. This requires more in-depth knowledge of AS–Interface, but is an extensive means for the analysis of errors, including those caused by the application software. The stored frames (figure 6) will be used as a base, established by the trigger and filter conditions, which can then be analysed offline. All described functions are available for this. The user can review the entire stored data, in which each message is listed separately. He can also select another filter for this data or analyse the messages before the error occurred. If necessary the erroneous signals can be analysed with an analog storing oscilloscope (online).
Two examples are shown: In figure 10 for a loose connection and in figure 11 for an analog input.
Nearly any message sequence can be checked in a similar way: The transmission of safe slaves according to the "Safety at work" specification can be checked, the notification of periphery faults can be displayed, or the transmission of erroneous messages can be shown in a time-related context. The success of corrections can be checked in detail. We do not have to stress here that this is a very powerful tool for users who are accustomed to the details of AS–Interface.
In addition to analysing a network the analyser can check an application. There is no PLC, no PC and no other host that provides data as detailed on an application as the analyser. The analyser can therefore be used to check the application itself. In this case one is not interested in the data in the context of the AS–Interface cycle, but in the context of the application. The trigger is then set by the application to identify a certain event. If necessary the recording process can be started via the input trigger in a way that changes in the system will be recorded in the time before the error occurs.
Errors due to the application or the surroundings can thus be found, for example the disturbance of the network due to the start of a motor. Malfunctions can be analysed or timing sequences can be optimised. As an example, the time between the command to close a valve and the arrival in its end position can be monitored and the timing can be optimised.
Bihl+Wiedemann offers the AS–Interface community an extremely powerful analysing tool on the digital level, as it has only been available for higher bus systems. Anyone frequently using AS–Interface will enjoy using this tool during installation to record the configuration, to prove the functioning of a network according to the specification, to detect errors and to avoid later failures. A specialist will be able to do even more with this analyser. Such a tool has been lacking so far.
 |
Article as PDF |
Literature
(1) Madelung, O.W.: Safety at Work?
Of course! And convenient! (A master with application functions);
www.bihl-wiedemann.de
(2) Bihl + Wiedemann: see:
www.bihl-wiedemann.de
(3) Madelung, O.W.: Supplement to the
AS–Interface Handbook (2nd edition), download-file under
www.madelung-online.de, 2001
Author
Dr. Otto W. Madelung, Technical
Consultancy Dr. Madelung, www.madelung-online.de