CODESYS Β· Track 10 Β· the serious end

Safety & Security

Two different jobs that get confused. Safety protects people from the machine. CODESYS Safety is a separate, certified runtime for SIL 3 logic. Security protects the controller from attackers with encryption, user management and signed apps. You need both, and they're not the same thing.

🟨 CODESYS SafetyπŸ” encrypted commsπŸ” signed boot app
01 Β· Safety β‰  Security

Two protections, side by side

On the left, CODESYS Safety runs on its own certified runtime, isolated from your standard application, so a bug in normal logic can never compromise the safe function. On the right, work through the security checklist to harden the controller against attackers and watch the score climb.

🟨 Functional Safety
Standard runtime
Your everyday application: POUs, motion, HMI. It can fail, restart and be edited freely.
β–² isolated Β· one-way status only β–²
CODESYS Safety runtime (SIL 3 / PL e)
A separate, certified runtime running safety POUs (Safety C / safety FBs). E-stops, light curtains, safe torque off. Independently validated & signed.

The safety side keeps people safe whatever the standard app does. It is the same "separate protected world" idea as Siemens F-CPU and Rockwell GuardLogix.

πŸ” Cyber-hardening
0
Unprotected
tick the controls β†’

Why keep them separate? Safety is about random & systematic failures (certified, validated, signed). Security is about deliberate attacks (defence in depth). A controller can be perfectly safe and still wide open to the network, or locked down tight with no safety function at all. Modern machines need both, designed in from the start.

02 Β· Check yourself

Which is which?

An auditor asks why the E-stop logic runs on a separate CODESYS Safety runtime instead of in your main application.