Access protection, fault detection and machine safety

Features relevant to safety and security in smart relays fall into three practical areas: restricting access, detecting faults and checking operating conditions. An ordinary smart relay does not become a safety relay by having these features. What is available depends on the controller type, exact hardware and firmware.

1. Passwords and permission to change the program

Depending on the model, password protection may restrict program editing, deletion, parameter changes or RUN/STOP selection. An operator might be allowed to adjust a timer while being prevented from changing the main sequence. Check the scope in the programming tools and supported programming options.

This helps control accidental or unauthorized changes. It does not prevent electrical failures, welded contacts or errors in the control logic. Establish whether protection covers reading the project, modifying it or only selected menus.

2. Protection of network access

Some connected models offer user roles, secure communication and secure boot. Siemens identifies these features for LOGO! 9; they should not be assumed for every earlier LOGO! generation or every smart relay. Consider industrial cybersecurity whenever the controller supports remote connections.

A working SCADA or Modbus connection is only the starting point. Check who can issue commands, which services are enabled and whether the chosen protocol supports authentication and encryption. Securing access does not, by itself, satisfy a machine’s functional safety requirements.

3. Diagnostics and cycle-time monitoring

Available features may include error codes, RUN/STOP status, I/O monitoring and expansion diagnostics. Some controllers provide a watchdog that detects a program cycle exceeding a configured limit. The response may be an alarm or STOP. Verify its configuration, limits and operating-mode restrictions; a watchdog is not a detector for every possible fault.

During fault finding, an output shown as off does not prove that its physical contact has opened: the contact may be welded. Likewise, an input display does not establish that a sensor is measuring correctly. Review the I/O arrangement and any feedback needed for the application.

4. Protective conditions built into the application

Appropriate sensors can support checks for low level, high pressure, excessive temperature or missing flow. A pump sequence might use a timer to raise an alarm when flow feedback fails to appear after a start command. This depends on the sensors and implemented logic; it is not a built-in capability shared by all controllers.

An NC contact can help reveal some broken-wire conditions, but does not establish a safety category or performance level on its own. Shorts, stuck sensors and incorrect feedback also need consideration. Process protection and a safety function protecting people from hazardous movement have different requirements.

5. Power restoration and restart behaviour

After a power interruption, RUN startup, retained variables and initialization depend on the controller and settings. A retained run request can cause an unexpected restart. Define startup conditions in ladder logic or FBD; measures protecting people against unexpected startup need an appropriate safety architecture.

Releasing an emergency-stop device must not automatically restart the machine. Reset can permit a restart, while starting requires a separate deliberate action. A controller’s STOP mode also does not replace energy isolation and control of stored energy during maintenance.

6. Electrical protection and the panel environment

Some transistor outputs include short-circuit or overload protection, but this must be checked for the exact model. Mechanical relay outputs require attention to contact ratings, load type and electrical life. Appropriate fuses, contactors, motor protection and wiring remain necessary where the circuit requires them.

Temperature limits, humidity, electromagnetic effects and the IP rating affect reliable operation. Protecting the controller electrically and validating a machine safety function are separate assessments.

Where can a standard smart relay fit in an emergency-stop system?

On a conveyor, it can manage the normal operating sequence and status messages. The emergency-stop function is implemented using a suitable safety relay or safety PLC, together with the required final switching elements, as determined by risk assessment. The ordinary controller may read suitable status feedback; its monitoring must not become a prerequisite for the safety circuit to work.

Under ISO 13849 or IEC 62061, the required PL or SIL applies to the complete safety function. Consider sensing, logic, final elements, wiring, failure behaviour and validation together. An “emergency stop” label in the program, or a certificate for one component, does not establish the achieved level of the whole circuit.

What should commissioning establish?

Use an appropriate test plan to check permissions, power restoration, communication loss, sensor failures and output behaviour. Keep a backup of the program and settings, and conduct tests under safe conditions. Simulation helps assess logic, but cannot validate physical hardware faults or actual stopping behaviour on its own. Safety functions require their own analysis and testing.

Technical references: Schneider Electric — Zelio Logic · Siemens — LOGO! · Eaton — RUN/STOP · ISO — ISO 13849-2 · Pilz — emergency-stop reset