SafetyNET p — Safe Real-Time Ethernet & Connections

Safety Network International · advanced · 30 min

SafetyNET p carries machinery-safety and standard data over one deterministic real-time Ethernet, using publisher/subscriber connections between named endpoints. Learn how it works and how to diagnose a safety connection that won't come up between two controllers.

ℹ️ SafetyNET p (a Pilz protocol, managed by Safety Network International e.V.) is a deterministic real-time safety Ethernet — the successor to SafetyBUS p. It's publisher/subscriber: each participant must know its partner(s), and safety is enforced at the communication endpoints, not the wire.

What SafetyNET p is

SafetyNET p is a deterministic, real-time Ethernet protocol that carries both machinery-safety data and standard automation data over the same network. It's a registered trademark of Pilz and the successor to SafetyBUS p, and the technology is managed by the umbrella organisation Safety Network International e.V., which provides product-neutral integration utilities and development support to member companies. It's used with Pilz PSS / PNOZmulti safety controllers and compatible devices.

How the safety connection works

Understanding the model is what makes diagnosis possible:

• Publisher/subscriber: each participant knows its communication partner(s) and exchanges data with them directly, rather than everyone talking to a single master.
• Safety at the endpoints: safety integrity is ensured at the SafetyNET p communication endpoints — the safety layer (sequence numbers, CRCs, timeouts, unique connection IDs) rides on top of standard Ethernet, so the network switches don't need to be "safe."
• Real-time: with SafetyNET p RTFL and the protocol chip, scan times down to 62.5 ms are supported — the safety data is delivered deterministically, not best-effort.

Diagnosing a connection that won't establish

When a SafetyNET p safety connection between two controllers (e.g. two PNOZmulti / PSS) won't come up, it's almost always an endpoint configuration or timing mismatch, because the wire itself is ordinary Ethernet:

1. Partner identity / connection IDs — each endpoint must be configured to expect the correct partner. A mismatched or duplicated connection/participant ID means the subscriber rejects the publisher's safety telegrams.
2. Publisher and subscriber both configured — a publisher with no matching subscriber (or vice-versa) never forms the connection.
3. Watchdog / timeout — the safety layer drops the connection if telegrams don't arrive within the configured time; too-tight timeouts on a loaded network cause intermittent safety trips.
4. IP addressing / subnet — standard Ethernet basics still apply: correct IP, subnet, and reachable path between the endpoints.
5. Configuration report — build and check the connection configuration (Pilz publishes application notes for building a SafetyNET p connection between two devices); a documented, matching config on both ends is the goal.

Step-by-step

1. Confirm both endpoints exist — a publisher and a matching subscriber, each expecting the other.
2. Check connection/participant IDs match on both ends (no duplicates).
3. Verify IP/subnet and a reachable Ethernet path between the two.
4. Review the safety watchdog/timeout — loosen if a loaded network causes nuisance drops (within your safety validation).
5. Document the configuration on both ends and re-validate the safety function.

Never do this

Never "fix" nuisance safety-connection timeouts by stretching the watchdog beyond what your risk assessment allows, or by moving safety traffic onto a congested general network — the timing is part of the safety function. Solve the real cause (network load, addressing, or endpoint config) and re-validate.