Track 08 built the safety program; this deep dive is how it becomes legally and demonstrably safe. Three artifacts run that show: the collective F-signature (a fingerprint of the validated safety program), the acceptance test (provoke every fault, on purpose, with a stopwatch), and the signed protocol that ties them together. Change one bit of F-logic and all three must be revisited — by design.
Every F-block gets a checksum, and the whole F-program gets a collective F-signature — visible in the Safety Administration editor, printed on the acceptance protocol, and checked at every audit. The deal is simple: protocol signature = online signature → the validated program is what's running. Edit blocks below and watch what moves the fingerprint — and what doesn't.
Notice the asymmetry: editing standard blocks never moves the F-signature — normal machine development continues freely. Touch anything yellow and the fingerprint changes instantly, the protocol no longer describes the running program, and the legal status reverts to "not accepted" until someone re-validates and re-signs. The signature is what makes "nobody quietly changed the safety logic" a checkable fact instead of a hope.
Certified components prove the parts; only the acceptance test proves your application. The method is gleeful sabotage: provoke every failure the risk assessment imagined and verify the system answers each one safely — with measured times, recorded values and a signature at the bottom. Run the protocol:
🔐 Safety Administration editor. The cockpit for all of this: offline vs online F-signatures, the F-runtime group status, access protection (the safety password), and the change log. First stop on any safety audit — and the place you check before AND after every download.
🚫 No forcing, no shortcuts. F-I/O cannot be forced like standard I/O — the F-system treats a force as the integrity violation it is. The disable/passivation mechanisms that DO exist for commissioning are logged, time-limited, and visible on the HMI. If a test needs a signal faked, you fake it at the sensor, physically.
📝 Change = impact analysis + partial re-test. Not every change re-tests everything: swap a like-for-like F-module and you re-verify that channel (F-address, signature unchanged, function test). Change F-logic and the affected functions get re-validated, new signature, new protocol page. The analysis of WHAT a change touches is itself a documented step.
👤 Who signs matters. The acceptance signature belongs to a competent person who witnessed the tests — typically not the programmer. Separating builder from validator isn't bureaucracy; it's the same two-channel principle the hardware uses, applied to humans.
A technician adjusts a delay inside FB_GuardDoor (an F-block) to stop a nuisance trip, downloads, and production resumes. The machine runs fine. What's the safety status of this machine?