Intelligence at a local level

Decentralisation of intelligence is rapidly creeping up the agenda of many firms, especially those operating with significant automation and control infrastructures. This approach neatly couples with the fact that software-based, factory-wide enterprise systems are giving those in charge the capability of an interactive view of their factories, products and processes from their desktop.

In response to this growing trend, automation companies are starting to add more intelligence to a wider range of their components, including those further down the complexity scale.

Intelligent products
One example of components being given added intelligence is the introduction of advanced two-way communications capabilities by Moeller Electric to its NZM range of moulded-case circuit-breakers (mccb).

The crux of the NZM's communications capability lies with a data management interface (dmi). This acts as an intelligent mid-point between the mccbs and higher level systems through the use of specialised interfaces and a digital I/O. This I/O can be used for further functionality within the mccb or to connect non-networked components such as fans or pumps to a fieldbus network through potential-free, binary 24 Vdc signals.

The communications capabilities were incorporated to enable diagnostic and operational data monitoring and parametric programming and control of the mccb by a higher-level controller or interface. The primary purpose is to allow complete visualisation of the device and its operational data.

Signal benefits
For diagnostics management, alarm signals such as over-current, phase imbalance or over-voltage enable users to intervene in the process to prevent system breakdowns and counter the inherent costs involved with factory downtime.

When dealing with fault management, tripped signals such as earth faults or short circuits give instant, localised information about where and why the power failed.

Analysis of the number of times a device has tripped or the level of the tripping currents can be used for preventative maintenance, which can be both event and time-driven. This can prevent costly downtime and damage to critical system parts.

Communications
Initially available with Profibus communicability, the dmi, which connects to the three models in Moeller's NZM range with electronic release, are due to have ASi, CAN open and DeviceNet capabilities in the future.

Profibus was chosen as the first protocol to be adopted due to its proliferation in the UK and Europe. ASi, being a device level language, was a natural choice for the near future as was CAN open for its inherently open nature. DeviceNet will be of interest to those in the US markets or running DeviceNet systems.

The NZM can communicate a variety of signals to the dmi, recording the latest ten time-stamped events. These include status signals such as current value, operational status, event messaging, maintenance data, number of times tripped, circuit-breaker diagnosis and specific device data such as type and serial number. Parametric information includes all trip release limits, diagnostics, time stamps, readings from six binary signals in the circuit-breaker, programming of six digital outputs with binary circuit-breaker status data and preparation of parameter values for later use.

Alarms can also be configured. These include load pre-warning, overload, load shedding, earth faults and over-temperature conditions. The type of trip release can also be identified and assigned to each of the six digital outputs.

The NZM can be programmed manually using dials on its front facia. When used in conjunction with the dmi, these dials can revert to representing upper limits with the dmi and parametric software determining actual trip limits below these dial-set values.

Software settings
Windows-based software can be supplied to configure the NZM and how, through the use of the dmi, it then communicates with equipment or networks higher up the control chain.

The software is intelligent enough to determine optimum settings for certain hardware and operating scenarios. Once the user has input the necessary data regarding the type and model of the mccb, they will have the option to specify other complimentary hardware peripherals, for example, motor starters (star/delta), some of which may demand the use of certain I/O addresses. Once allocated by the software, these I/O points will be frozen and made unavailable to the user.

After the physical characteristics of the equipment have been entered, the user can simply input the operational details and determine the events that will trigger the individual alarms and to which outputs these are consigned.

Using the system
A graphical text display is presented to the user, giving a real time snapshot of the operating conditions such as current levels, status indicators and time and date details.

A further screen will list trips, their causes and when they happened, so users will have a more concise picture of the nature of the operating conditions of their hardware. The software offers a substantial help section that incorporates a full glossary of terms and examples, should the user need to get an idea of context or application.