Source portability
The owner receives editable application source in the agreed language and format, with no inaccessible generated logic required to maintain it.
Home › O-PAS Application Portability
IEC 61131 · Control Applications · Ownership · Verification
O-PAS application portability Make control knowledge movable by design
Application portability is not a label attached to source code. It is a project outcome created by architecture, disciplined use of IEC 61131, controlled dependencies, complete owner deliverables and a test that proves the application can move.
The short answer
O-PAS alignment and use of an IEC 61131 language do not, by themselves, prove that a control application is portable. Portability exists when an owner can take the complete application package, deploy it in an intended compatible environment without redesigning the control strategy, and demonstrate equivalent required behaviour through an agreed test.
The project must define the language and feature set, runtime assumptions, libraries, interfaces, data model, timing, security, system services, deployment method, ownership, documentation and acceptance evidence. Any dependency left implicit can become the proprietary boundary that prevents the application from moving.
01 · Definition
Portability has several layers, and all of them matter
An application can be readable outside its original tool and still be expensive or impossible to operate elsewhere. The claim must identify exactly what moves and what work remains.
Semantic portability
Logic, data types, task behaviour and function semantics retain their intended meaning in the target environment.
Build portability
The application can be compiled or prepared using documented tools, versions, libraries, settings and dependencies.
Deployment portability
The package can be installed, configured, versioned and rolled back through the target environment's approved workflow.
Runtime portability
The application executes within required timing, resource, communication, redundancy and recovery limits.
Lifecycle portability
The owner can maintain, test, update and move the application after the original supplier and project team have gone.
The acceptance rule
A statement that an application is portable should name the source environment, target environment, application baseline, permitted changes, required behaviour and test evidence. Without those boundaries, portability is an aspiration rather than an acceptance criterion.
02 · Language
IEC 61131 provides a common application foundation, not automatic interchangeability
IEC 61131 control applications are the practical centre of most industrial control work. Standard languages create a common engineering basis, but the delivered application can still depend on implementation choices outside the language.
What it helps
A common expression of control intent
Standard languages, program organisation concepts and data constructs reduce the amount of control knowledge trapped in an entirely proprietary representation.
What remains
Runtime and tool behaviour
Scheduling, timing, persistence, data representation, diagnostics, online change, redundancy and resource limits can differ between environments.
Libraries
Function blocks can carry the dependency
A standard language can call a vendor-specific library. If that library cannot move, the application is only as portable as its most important dependency.
Extensions
Convenient features need an explicit decision
Vendor extensions may be valuable, but each one should be identified, justified and assigned a migration or replacement strategy.
Do not reduce the requirement to “use IEC 61131.” Name the language or languages, permitted feature set, coding rules, library policy, interfaces, timing assumptions, deployment method and evidence required to demonstrate the intended portability boundary.
03 · Dependency control
Lock-in usually returns through dependencies, not through the control equation
The core algorithm may be straightforward. The difficulty sits in everything the application expects around it.
| Dependency | Question to resolve | Evidence to require |
|---|---|---|
| Libraries and function blocks | Are they standard, owner-controlled, licensed, replaceable or tied to one environment? | Source or documented interface, version, licence rights, tests and replacement position. |
| Task and scheduling model | What cycle, priority, event and execution-order assumptions affect behaviour? | Task configuration, timing budget and representative load test. |
| I/O and communications | How are field data, peer data, quality, timestamps and failure states presented? | Interface definitions, mappings, data semantics and boundary tests. |
| System services | Does the application call alarms, historians, identity, time, diagnostics or management services? | Service catalogue, API or interface definition, error behaviour and fallback requirements. |
| Data types and persistence | How are values represented, retained, initialised, converted and recovered? | Data dictionary, persistence rules, restart tests and conversion records. |
| Engineering toolchain | Which tool, plug-in, compiler, licence and version are needed to build and maintain the application? | Build instructions, tool versions, licences, clean-build record and owner access. |
| Cybersecurity controls | Which identities, permissions, certificates, signing or approval workflows govern deployment? | Security roles, credential process, signing records and deployment audit evidence. |
| Hardware or runtime features | Does the logic rely on a specific processor, accelerator, redundancy model or proprietary runtime service? | Resource profile, dependency statement, performance limits and target-environment test. |
04 · Handover
Define the portable application package as an owner asset
Source code without its dependencies, configuration and evidence is not a complete handover. The package should be sufficient for a competent team to reproduce the approved application baseline.
Editable application source
Programs, function blocks, functions, data types, declarations, comments and configuration under version control.
All required dependencies
Library source where required, binaries where permitted, versions, licences, provenance and interface documentation.
Reproducible build record
Tools, compiler, plug-ins, settings, scripts, environment versions and instructions for a clean build.
Deployment package
Runtime configuration, mappings, security requirements, target parameters, release notes and rollback package.
Requirements and design basis
Control narratives, cause-and-effect, sequence descriptions, interfaces, assumptions and traceability to implementation.
Tests and accepted results
Unit, integration, performance, failure, recovery, regression and functional-equivalence procedures with records.
The contract should state ownership and continuing use rights for every item, including supplier-developed libraries and build assets. Delivery alone does not resolve whether the owner is legally or technically able to reuse them.
05 · Procurement
Seven requirements to write before application work starts
Portability is easiest to preserve before tools, libraries and coding practices have created dependencies. Recovery after implementation is usually a redevelopment project.
Define the portability objective
Name the business reason, intended target environments, application classes in scope and acceptable level of conversion or rework.
Set the application rules
Specify IEC 61131 language, coding standard, feature policy, naming, modularity, documentation, version control and review requirements.
Control libraries and extensions
Identify approved libraries, ownership, source requirements, version control, qualification, vendor extensions and the process for exceptions.
Define runtime and interface assumptions
State task behaviour, timing, resources, persistence, I/O semantics, communications, system services, security and failure handling.
Require a complete handover package
List source, libraries, build environment, configurations, mappings, deployment files, licences, documentation, tests and records.
Assign responsibility for the move
Name who supplies the target environment, prepares the package, resolves dependencies, performs conversion, executes tests and pays for correction.
Define the acceptance demonstration
Specify the source and target baselines, permitted changes, test environment, representative load, required behaviour, tolerances and acceptance authority.
Carry these requirements into the RFQ using the O-PAS Procurement Specification Checklist and allocate the work with the O-PAS Responsibility Matrix.
06 · Verification
The portability proof test
The strongest evidence is a controlled move using the same deliverables and process the owner will rely on during the system lifecycle.
| Step | Demonstration | Acceptance evidence |
|---|---|---|
| 1. Freeze the baseline | Identify the approved source application, runtime, versions, configuration and required behaviour. | Signed baseline, checksums or version identifiers and approved test reference. |
| 2. Assemble the package | Deliver only the contracted owner handover assets, not undocumented supplier knowledge. | Package manifest, dependency list and completeness review. |
| 3. Prepare a clean target | Use the named compatible target environment without hidden remnants of the source toolchain. | Target baseline, installed tools and environment record. |
| 4. Build and deploy | Compile or prepare, configure and deploy through the documented workflow. | Build log, deployment log, warnings, changes and elapsed engineering effort. |
| 5. Resolve permitted differences | Apply only the conversion explicitly allowed by the acceptance plan. | Change record separating configuration, mapping, library substitution and logic redesign. |
| 6. Execute the test suite | Test normal operation, sequences, interlocks, timing, limits, bad data, communication loss, restart and recovery. | Approved results under representative load and failure conditions. |
| 7. Compare behaviour | Demonstrate required functional equivalence within defined tolerances. | Traceable comparison, accepted deviations and residual limitations. |
| 8. Prove lifecycle control | Modify, version, redeploy, roll back, back up and restore the moved application. | Lifecycle procedure and witnessed records showing repeatability. |
Opening or importing the source file.
Building and deploying without logic redesign.
Passing functional and non-functional tests.
Repeating the lifecycle workflow under owner control.
Application portability should be tested inside the wider project verification programme. Use the O-PAS FAT and Interoperability Testing Guide to connect application evidence to interface, resilience, recovery and acceptance testing.
07 · Brownfield decisions
Not every legacy application should be moved the same way
The migration method should reflect application condition, business value, dependencies and the quality of the available baseline.
| Decision | Best fit | Primary caution |
|---|---|---|
| Reuse | The application already follows the intended language, library and dependency rules and can pass the target proof test. | Imported code may still carry hidden runtime or library assumptions. |
| Translate | The control intent is sound, source is available and differences can be resolved through controlled conversion. | Automated conversion can preserve obsolete structure and create difficult-to-maintain output. |
| Re-engineer | The operating requirement remains valid but the implementation is undocumented, tightly coupled or structurally weak. | Functional equivalence and intentional improvements must be separated and tested. |
| Replace | A supported application or newly designed module better meets the requirement than preserving the legacy logic. | New functionality can change operator workflow, failure behaviour and validation scope. |
| Retire | The function is obsolete, duplicated, unused or no longer supported by an operating requirement. | Dead-looking logic may still protect an undocumented operating condition. |
Use the Brownfield OPA Migration Strategy to place application work inside the facility sequence, coexistence plan, cutover gates and rollback model.
08 · Operating model
Portability has to survive project handover
The owner needs a repeatable lifecycle process, not a one-time demonstration performed by the original supplier team. Use the O-PAS System Management and Lifecycle Operations Guide →
Application architecture owner
Controls language, libraries, interfaces, exception decisions and the long-term portability baseline.
Owner-controlled configuration
Maintains source, dependencies, deployment packages, documentation and accepted test assets under change control.
Build and deployment governance
Defines who may build, approve, sign, deploy, roll back and restore each application release.
Dependency review
Checks whether patches, library updates, substitutions or new features narrow the portability boundary.
Regression evidence
Keeps the test suite usable so future moves and upgrades can be verified against approved behaviour.
Owner and integrator competence
Ensures the organisation can maintain the package without relying on undocumented knowledge held by one person or supplier.
09 · Lifecycle value
Value portability as avoided future engineering, not as a feature claim
The economic value comes from changing the work required at future refresh, migration and supplier-change events.
Baseline
Cost of a bound application
Estimate conversion or redevelopment, library replacement, interface rebuilding, testing, revalidation, commissioning, training and production exposure at each expected lifecycle event.
Portable case
Cost of a controlled move
Include packaging, dependency control, proof testing, ongoing governance and the residual conversion still expected between compatible environments.
Sensitivity
Test the assumptions
Vary the number of reusable applications, engineering hours avoided, frequency of moves, target compatibility, test effort and value of supplier choice.
Evidence
Separate demonstrated from assumed
Give greater weight to witnessed moves, measured engineering effort and accepted test results than to general claims about language or platform openness.
Model these lifecycle differences with the Open Process Automation Business Case Guide and the CSI OPA Lifecycle Value Model.
10 · Related guidance
Connect application portability to the rest of the project
Procurement
O-PAS Specification Checklist
Write architecture, application, evidence, handover and lifecycle obligations into the procurement package.
MigrationBrownfield OPA Migration Strategy
Sequence application work with coexistence, integration, cutover, rollback and stabilisation.
Owner decisionOPA for Owner-Operators
Connect portability to business case, architecture, sourcing, governance and the operating model.
11 · FAQ
O-PAS application portability questions
Does IEC 61131 make a control application portable?
IEC 61131 provides a common language and application foundation, but portability also depends on libraries, extensions, task behaviour, runtime services, interfaces, data handling, toolchains and deployment methods. The intended source and target environments still need a defined proof test.
Does O-PAS conformance guarantee application portability?
No. Product conformance addresses the product and profiles within the certification scope. Application portability is a system and project outcome that depends on the selected environments, application design, dependencies, deliverables and verification.
What should be included in a portable control-application package?
Editable source, required libraries, versions, licences, build instructions, toolchain details, runtime configuration, mappings, deployment and rollback packages, design documentation, interfaces, dependencies, test procedures and accepted results.
How should application portability be tested?
Freeze the approved source baseline, assemble only the contracted handover package, prepare a clean target environment, build and deploy through the documented process, record all changes, execute representative functional and non-functional tests, compare required behaviour and demonstrate versioning, rollback, backup and recovery.
Can vendor-specific function blocks be used?
Yes, if the project makes the dependency explicit and accepts its lifecycle effect. The specification should state ownership, licence, source or interface availability, replacement strategy, qualification requirements and what happens when the application moves.
Who should own the application portability requirement?
The owner should define the lifecycle objective and retain architecture and acceptance authority. The EPC or system integrator should translate it into executable requirements, while application and product suppliers provide the assigned deliverables, dependency evidence and correction support.
Protect the control intellectual property
Define portability before the application is built
CSI helps owners and EPC teams define IEC 61131 application requirements, control dependencies, owner deliverables, migration methods and proof tests before tool and supplier decisions make the application difficult to move.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. References to application portability describe project requirements and verification outcomes; they do not imply that every IEC 61131 application or O-PAS-conformant product is interchangeable without engineering and testing.