Honeywell Experion Batch Recipe Versioning with Git | Engineering Service

Key Takeaways

Honeywell Experion Batch does not provide documented, native Git integration; Git can be used as an external canonical repository if recipes are exported to a deterministic text format. (See Honeywell Experion Batch architecture.) (https://www.scribd.com/document/467234262/2019-hug-america-batch-funamentals-1-coral)
Use a canonical, machine-readable recipe representation (XML/JSON) and strict export/import tooling to avoid divergence between Experion and the Git repository.
Implement cryptographic signing, server-side hooks, and controlled workflows to meet audit and 21 CFR Part 11-style requirements; pair Git audit trails with Experion/Batch Historian logs for end-to-end traceability. (https://process.honeywell.com/content/dam/process/en/documents/document-lists/hon-ia-hps-life-sciences-batchhistorian-solutionnote-2024.pdf)
Adopt branching, tagging, CI validation, and staged deployments to enable safe rollbacks and reproducible releases in regulated plants.
Validate with Honeywell and capture change-control evidence as part of formal quality management and validation deliverables. (https://process.honeywell.com/us/en/solutions/batch-automation)

Why Git for Experion Batch recipes?

Honeywell Experion Batch implements ISA‑S88 concepts using class- and instance-based recipes and a layered control architecture (SCM/CM/Data Blocks) [1]. Experion stores recipes in its configuration database, optimised for execution and engineering life cycle management. It does not, however, publish an off‑the‑shelf Git integration. For plants that require modern source control, we recommend a controlled, external Git workflow that treats the Experion recipe store as the authoritative runtime source while using Git as the canonical engineering repository for versioning, code review, CI/CD and rollback control.

External Git usage brings benefits: diff/merge tools, signed commits, immutable tags, code review and automation pipelines. It also introduces risk: dual copies of truth (Experion DB vs Git), potential manual divergence, and regulatory gaps unless the workflow enforces traceability and tamper-evidence.

References: Honeywell documentation and solution notes for Experion/Batch and Batch Historian describe recipe models and historian capture capabilities [1][2][3].

Architecture and constraints

Experion Batch recipe model

Experion supports:

Class-based (template) recipes
Instance-based (per-batch) recipes and executions

Its runtime elements include SCM, Control Modules and Data Blocks that map parameters to recipe fields [1]. Recent Experion PKS and Batch Historian releases provide enhanced connectivity and batch capture but do not change the proprietary configuration store model [2][5][6].

Practical constraints

Export format: Honeywell tools often export configuration in proprietary XML or structured files, not a native Git-ready format.
Metadata: Recipe metadata required for batch traceability (revision ID, effective date, approver) must be included.
Regulatory recordkeeping: 21 CFR Part 11–type controls require audit trails and signature capture — Git’s audit trail can help but does not replace validated system controls.

Design patterns for Git-based recipe versioning

Canonical text representation

Define a canonical, deterministic export format:

Use a structured XML or JSON schema that captures all recipe elements, parameter defaults, S88 class mapping and references to Control Modules/Data Blocks.
Normalize export order and whitespace so diffs are meaningful.
Include embedded metadata (recipe ID, S88 class/version, author, approval stamps).

Automate exports from Experion into this canonical format via validated scripts or APIs; store these exports in Git. If Experion export isn’t supported via API, use engineered, repeatable export procedures and checksum verification.

Repository layout and branching

Adopt a clear repo layout and branching model:

/recipes/class//.xml
/recipes/instance//.xml (if you track instances)
Branching: main (production), release/* (approved releases), feature/* (engineering changes), hotfix/* (emergency updates)
Tag releases with annotated, GPG-signed tags that map to approved change control numbers.

Suggested branching workflow mirrors Git Flow but simplified for regulated operations: feature → release/QA → main.

Commit, review and approval

Enforce signed commits and signed tags (GPG) for approved merges.
Use pull requests for changes, with at least one approver from process engineering and QA.
Capture approval IDs and electronic signature metadata in the recipe header and in CI artifacts.

Security, auditability, and regulatory compliance

Audit trail design

Combine Git auditability with Experion and Batch Historian logs:

Store commit hashes and tag IDs inside recipe metadata and in the Experion recipe description field. This creates a cross-reference between Git and runtime.
Ensure Batch Historian captures batch execution context that includes the recipe commit hash (use Batch Historian configuration to add custom metadata where possible) [2].

Electronic signatures and tamper evidence

Use GPG-signed tags for release approval. Store signed artifacts (release ZIP with checksums) in an immutable artifact feed.
Implement server-side hooks that reject unsigned merges into release/main.
Maintain access control with LDAP/AD integration for both Git and Experion engineering accounts.

Validation and 21 CFR Part 11 considerations

Treat the Git repository as part of the validated toolchain. Define user access, backup, retention and restore procedures in validation documentation.
Document how Git audit entries, signed tags, Experion change logs and Batch Historian records together satisfy record integrity and non-repudiation requirements.
Keep a QA-controlled SOP describing the export/import, deployment and rollback procedures.

CI/CD, deployment and rollback strategies

Validation pipeline

Create CI jobs to:

Syntax-validate exported XML/JSON against the canonical schema
Run static checks (unused parameters, naming conventions)
Run simulation tests against a non-production Experion simulator or test host
Produce an artifact (signed ZIP + checksum) when QA approves

Deployment

Stage: Deploy to staging Experion node using automated import scripts that perform a configuration backup before import.
Production: After staged verification, promote artifact to production using an automated, logged import process that writes the commit/tag ID into the Experion recipe metadata and records the change in Batch Historian.

Rollback

Use Git tags to identify last-known-good release; CI/CD should provide an automated rollback job that:
- Restores a pre-change configuration snapshot on the Experion node
- Re-imports the recipe artifact (signed) associated with the tagged release
- Logs the rollback with reason and references to the change control ticket

Maintain configuration backups and versioned exports to ensure rollback atomicity.

Traceability: linking batches to commits

When a batch executes, include the recipe commit hash in the batch execution header or as an execution text field. Use Batch Historian to capture this field for reporting and audits [2].
Use traceability scripts to generate an evidence package: recipe file at specific commit, change request ID, approvals, CI logs and deployment logs.

Comparison: Native Experion repository vs Git-backed approach

| Capability | Native Experion Repository | Git-backed Repository | |---|---:|---| | Execution-integrated storage | Yes | No (external canonical repo) | | Rich batch metadata capture | Yes (runtime) | Yes (as metadata files and CI artifacts) | | Code review & PR workflows | Limited | Full Git platform workflows (PRs, reviews) | | Signed releases | Limited | GPG-signed tags and signed artifacts | | Differential merges | Limited to toolset | Full diff/merge tools and text-based merges | | Regulatory audit trail | Experion logs + historian | Git audit + Experion + historian (composite solution) | | Rollback automation | Manual or tool-based | CI/CD-driven rollback using tags and artifacts |

Practical implementation checklist

Confirm supported export formats and APIs with Honeywell; validate exports for completeness [1][5][6].
Define canonical schema for recipe exports and implement deterministic exporters.
Build a Git repository with branch and tag policies; enable signed commits/tags.
Implement CI validation jobs and automated deployment/import scripts.
Integrate commit hashes into Experion recipe metadata and Batch Historian capture [2].
Document validation, change control and SOPs; execute formal IQ/OQ/PQ as required.
Perform a pilot on non-production Experion nodes and validate rollback scenarios.

Next Steps

To move from concept to production-ready implementation, our team can help with:

/services/scada-hmi-development — implement export/import tooling and integration with Experion
/services/plc-programming — align control module and data block mappings with recipe schema
/services/industrial-robotics — coordinate recipe-driven automation where robots integrate with batch processes
Review platform compatibility with /platforms/honeywell and cross-vendor strategies such as /platforms/rockwell-automation for multi-system environments
Learn more about version control best practices at /knowledge/version-control-best-practices