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 β€” encryption, user management, 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 the security checklist to harden the controller against attackers; watch the score climb.

🟨 Functional Safety
Standard runtime
Your everyday application β€” POUs, motion, HMI. Can fail, restart, 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 regardless of what the standard app does β€” 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 but with no safety function. 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.