Upgrading S7 F-Systems Software and Managing Safety CRC Changes in SIMATIC PCS 7

In SIMATIC PCS 7 and STEP 7 safety environments, replacing corrupted S7 F-Systems V6.0 installation media with S7 F-Systems V6.1 SP1 is supported on compatible operating systems. However, installing V6.1 SP1 introduces updated safety libraries (S7 F Systems Lib). If existing safety blocks are updated to the newer library version, the Safety Collective Signature (CRC) of the safety program will change, mandating complete safety re-testing, TÜV-compliant loop verification, and safety sign-off under IEC 61508 / IEC 61511.

Architecture of S7 F-Systems and Version Compatibility Rules

In process safety applications (burner management systems, emergency shutdown systems, toxic gas monitoring) running SIMATIC S7 F-Systems on S7-400F / S7-410F fail-safe controllers, safety logic is authored in CFC using certified fail-safe function blocks from the S7 F Systems Lib.

When an Engineering Station (ES) experiences hard drive corruption or operating system recovery, engineers must reinstall the safety engineering software:
* Previously installed version: S7 F-Systems V6.0.
* Available replacement media: S7 F-Systems V6.1 SP1.

Software installation itself is fully compatible: S7 F-Systems V6.1 SP1 can open, compile, and edit projects authored under V6.0.

However, in safety-instrumented systems, software updates carry profound legal and regulatory consequences:
1. Safety Library Version Mismatch: V6.1 SP1 includes an updated S7 F Systems Library. If the engineer expands the safety program using blocks from the new library while existing logic contains older V6.0 blocks, the safety compiler flags version discrepancies.
2. Safety Collective Signature (CRC) Invalidation: Updating existing blocks in the project to V6.1 SP1 alters compiled block algorithms and memory footprints. This recalculates the F-Program Collective Signature (CRC), requiring a safety turnaround.

S7 F-Systems Software and Safety Library Compatibility Matrix

Understand dependencies across S7 F-Systems engineering packages:

S7 F-Systems Software VersionBundled S7 F Systems LibraryCompatible STEP 7 VersionsCompatible PCS 7 VersionsCollective Signature Impact upon UpgradeS7 F-Systems V6.0S7 F Systems Lib V1.2STEP 7 V5.4 SP3/SP4PCS 7 V7.0, V7.1Baseline CRC establishedS7 F-Systems V6.1S7 F Systems Lib V1.3STEP 7 V5.4 SP5 / V5.5PCS 7 V7.1 SP2+, V8.0CRC changes if blocks updatedS7 F-Systems V6.1 SP1S7 F Systems Lib V1.3 SP1STEP 7 V5.5 SP2+PCS 7 V8.0 SP1, V8.1CRC changes if blocks updatedS7 F-Systems V6.2 / V6.3S7 F Systems Lib V1.3 SP2+STEP 7 V5.5 SP4+ / V5.6PCS 7 V8.2, V9.0, V9.1CRC changes if blocks updated

Safety regulatory notice: Verify software versions in the Siemens Compatibility Tool before installation.

Impact of Library Updates on Safety Collective Signatures (CRC)

Under functional safety standards (IEC 61508 / IEC 61511, SIL 3):
1. The Safety Collective Signature: Represents a cryptographic checksum encompassing all fail-safe block algorithms, execution sequence, F-I/O parameters, and interconnections.
2. Option 1: Engineering Without Block Update: If you install S7 F-Systems V6.1 SP1 but do NOT update the block types in the project, the compiler uses the existing V6.0 block templates in the offline block folder. The Safety CRC remains identical, permitting minor logic edits without full recertification. However, no new V6.1 module drivers can be introduced.
3. Option 2: Updating Block Types to V6.1: If you update the block types in SIMATIC Manager (Options > Plant Hierarchy > Update Block Types), the new V6.1 blocks replace the V6.0 blocks. The Safety CRC changes permanently, legally mandating a full functional test of every safety loop.

Step-by-Step Recovery and Safety Re-Validation Workflow

Follow this procedure to reinstall the engineering station safely:

Install S7 F-Systems V6.1 SP1:
* Insert the S7 F-Systems V6.1 SP1 installation CD.
* Run Setup.exe as Administrator.
* Install the engineering software and transfer the license via Automation License Manager (ALM).
Dearchive Project and Verify Initial Signature:
* Dearchive the verified plant safety project archive.
* Open the safety program in CFC: Edit > Safety Program.
* Compare the displayed offline Collective Signature against the signed commissioning safety documentation. They must match exactly.
If Retaining Existing CRC (No Turnaround Window):
* Do not click 'Update Block Types'.
* Make any required emergency logic modifications.
* Recompile: Only the modified rung signature updates; existing verified logic retains safety integrity.
If Modernizing to V6.1 Library (Planned Turnaround):
* Execute Update Block Types from S7 F Systems Lib V1.3.
* Recompile: Compile > Safety Program.
* Record the new Safety Collective Signature and compilation timestamp in the official plant safety logbook.
* Execute complete functional trip testing across all safety loops and obtain safety authority sign-off.

Verification

Verify safety program integrity:
1. In CFC, open the Safety Program dialog: Confirm that program status indicates: Consistent.
2. Download the safety program to the F-CPU: The controller verifies safety communication with all fail-safe distributed modules.
3. Confirm that the front panel SAFE LED illuminates solid green and SF (System Fault) remains dark.
4. Test an emergency shutdown push-button: Confirm fail-safe de-energization of the target digital output within the certified safety response time.

Limitations and Operational Precautions

Never download a safety program with an altered Safety CRC to an active production plant without coordinated bypasses and operator notification; safety downloads can cause momentary actuator freeze or fail-safe trips.
Always archive the safety program using the official S7 F-Systems Archive function, which seals the safety configuration with its cryptographic signature.
F-CPU power supply buffer batteries must be tested and fully charged before executing safety downloads.

Engineer FAQ

Can S7 F-Systems V6.1 SP1 compile an older V6.0 project without errors?

Yes. S7 F-Systems compilers maintain backwards compatibility and can compile projects containing legacy V6.0 safety blocks.

What happens if I mix V6.0 and V6.1 blocks in the same safety program?

While certain utility blocks can coexist, mixing different versions of channel drivers (e.g., F_CH_DI or F_CH_DO) triggers compiler consistency warnings and can degrade safety cycle times.