Asset Oriented Programming gives your PLC projects a structure that is easier to reuse, maintain, and hand over.
I help automation teams design practical PLC architectures, asset libraries, and coding standards that hold up in real projects. That might mean setting a standard for new work, tightening up a loosely standardised codebase, or planning a sensible route away from years of duplicated logic.
The goal is not theory for the sake of it. It is a structure your team can actually work with: predictable assets, clearer interfaces, less duplication, and a codebase that gets easier to support over time.
What This Service Covers
Architecture and Standards
Define the structure behind your PLC projects so engineers are not reinventing the same patterns from job to job.
- UDTs and data structures for common devices and systems
- Function Block patterns, naming conventions, and project organisation
- Clear separation between hardware, logic, and HMI-facing data
Refactoring Existing Code
Bring order to a codebase that has grown organically without trying to rewrite everything in one hit.
- Identify what is worth standardising first
- Spot duplicated logic, brittle interfaces, and awkward dependencies
- Plan a migration path that is practical for live projects
Asset and System Libraries
Create reusable building blocks that behave consistently across projects and sites.
- Standard asset behaviour for motors, valves, conveyors, and more
- Consistent alarms, interlocks, commands, and status handling
- Library structures that are easier to maintain over time
Rollout and Team Support
Turn a design approach into something your team can actually adopt and keep using.
- Pilot implementation support on real projects
- Documentation and examples to make the standard usable
- Guidance that helps other engineers work with confidence
What Is Asset Oriented Programming?
Asset Oriented Programming (AOP) is a structured design pattern for PLC automation that treats each physical device or logical system as a self-contained “asset” with standardized interfaces, behavior, and data structures.
The core principle is simple: every asset of the same type (motor, valve, conveyor, etc.) should work exactly the same way, with the same inputs, outputs, alarms, and control logic. This standardization makes your code predictable, testable, and genuinely reusable across projects.
Why It Helps
Reusability
Write an asset once, then keep reusing it instead of rebuilding the same logic for every project.
Maintainability
Improvements and fixes happen in one place, not across a long list of slightly different copies.
Testing and Simulation
Standard structures make isolated testing and simulation much easier to set up and trust.
Team Consistency
Once engineers understand the pattern, they can work across projects with far less handover friction.
The Structured Approach
Almost any project can benefit from a structured approach. The architecture is split into five basic layers, with additional optional layers for specific requirements:
1. Input Abstraction Layer
- Gathers information from physical hardware
- Stores signals in standardized input tags
- Isolates hardware dependencies from logic
- Provides foundation for simulation
2. Input Mapping Layer
- Copies input signals to Asset Data Blocks
- Uses User Defined Types (UDTs) for structure
- Ensures consistent data organization
- Creates standard interface for assets
3. Asset Management
- Library-managed Function Blocks control assets
- Handles alarms, status, and HMI integration
- Manages device-specific functionality
- Generates output requests and interlocks
4. Interlock Generation
- Assets create standard interlocks
- Stored in Asset Data Blocks
- Used by other devices and processes
- Optional omission for unused interlocks
5. Output Mapping Layer
- Extracts output requests from Asset Data Blocks
- Writes to physical output hardware
- Isolates control logic from I/O
- Simplifies hardware changes
Advanced Capabilities
Once the standard approach is in place, a lot of useful extras become much easier to build and maintain.
System Generation
Groups of assets that belong together can become reusable system-level building blocks with clearly defined dependencies.
Alarm Consistency
When assets follow the same structure, alarm handling becomes easier to configure, document, and troubleshoot across the whole project.
Simulation Layers
Structured data makes it much easier to insert simulation cleanly, test safely, and trust that assets behave the same way on site.
Who Is This For?
Starting from Scratch
You are setting a standard for a new project or a new internal way of working and want to get the structure right early.
Years of Existing Code
You have a lot of project history behind you, but reuse is limited because every job has drifted in a slightly different direction.
Loosely Standardised Projects
You already have some patterns, but they are inconsistent enough that reuse and handover still feel harder than they should.
Scaling Across Sites
You are deploying similar systems in multiple places and want them to stay maintainable rather than becoming site-specific one-offs.
Building a Team Standard
You need engineers to work across projects more easily, without every handover turning into a rediscovery exercise.
Reducing Technical Debt
You are tired of duplicated logic, one-off fixes, and improvements that never quite make it back into the wider codebase.
How This Usually Starts
Review the Current Position
We look at what code already exists, how consistent it really is, and what constraints the project or team is working under.
Define the Right Standard
The target structure depends on what you need most, whether that is reuse, maintainability, simulation, cleaner handover, or a more scalable library.
Agree the Next Practical Step
That might be a pilot implementation, a refactoring plan, a library review, or support shaping the standard with your team.
There is no one-size-fits-all package here. Some clients need a clean architecture for a new project. Others need help bringing years of existing code into a more usable structure. The first discussion is there to work out what will actually move things forward.
Platform Experience
I have experience with multiple PLC platforms:
- Siemens (TIA Portal, SIMATIC Manager)
- Allen Bradley / Rockwell Automation
- Schneider Electric
- Mitsubishi
- CODESYS-based platforms
However, the structured design principle applies to almost any modern PLC with symbolic programming capability. The concepts are platform-agnostic, even if the specific implementation details vary.
Real-World Experience
I work with structured PLC code in real production environments, including wastewater treatment plants, conveyor systems, and more complex industrial processes. That means the advice here is shaped by what is maintainable on site, not just what looks neat on a whiteboard.
I also create Asset Oriented Programming training content, so a big part of the work is helping teams understand the structure well enough to use it confidently after the initial engagement.
Check out my LinkedIn and blog posts for examples of the work I do and the approaches I take.
Book a Quick Architecture Discussion
If you are planning a new PLC standard, reviewing existing asset libraries, or trying to bring more structure to a growing codebase, use the calendar below to book a free, no-obligation 30-minute discussion.
We can use the call to talk through your current approach, what is getting in the way, and what kind of structured standard would make the most sense from here.