Sign in Subscribe
Blog

The Architecture Advantage: Why Proper Source Control & Reusable Components Determine ROI

Why version control and component-based architecture decide the ROI of your automation platform — applies to both PLC and HMI development.

Carter Gray

• 10 min read

How version control and component-based architecture eliminate ad hoc programming across PLC and HMI development

Most manufacturers and OEMs approach automation development with the wrong question. They ask: "How do we get this machine programmed and deployed?"

The right question is: "How do we architect our control systems so we never program the same thing twice?"

This isn't semantic. It's the difference between saving time on one project and fundamentally changing how you deploy machines for the next decade.

And it applies to both PLC and HMI development, regardless of platform.

The Version Drift Problem

This is when each machine becomes a separate copy that evolves independently.

Each machine starts as a copy of the master. Then it evolves independently. Bugs get fixed, features get added, structures get reorganized. After 6 months, Machine 31 and the current master have diverged so far that merging features between them takes days of work.

Version drift happens when you don't have: 

  • Component based design
  • Modern version control 
  • Tagged releases tracking what went where 
  • Visual history of changes 
  • Merge tools to handle conflicts 
  • Easy rollback capability

Instead you have:

  • Folders full of .ACD files named "Machine_31_Final_v2.ACD" 
  • HMI projects in "Backup_2024_Jan_DO_NOT_USE" directories
  • A "Current_Master" that isn't actually current 
  • Tribal knowledge: "Machine 38 has the good recipe logic, but don't use its alarm setup" 
  • Check-in/check-out tracking via Word document

And it costs you thousands of engineering hours per year.

The PLC Reality

You have a "master" PLC program. The base file that represents your standard machine.

When you build Machine 47:

  • Customer needs conveyor logic with accumulation (last used on Machine 31, developed 6 months ago)
  • Customer needs recipe management (last used on Machine 38, developed 4 months ago)

The problem:

  • Machine 31's .ACD is 6 months behind your current master program
  • Machine 38's .ACD is 4 months behind your current master program
  • You're opening old .ACD files and hunting through ladder logic

Your engineer's process:

  1. Open Machine 31's .ACD file from the archive
  2. Locate the conveyor accumulation logic (scattered across multiple routines)
  3. Realize Machine 31 has a different I/O structure than today's master
  4. Open Machine 38's .ACD file
  5. Find recipe management logic (stored in different data structures)
  6. Realize Machine 38's program structure was reorganized 3 months ago
  7. Try to extract both features into current master program
  8. Deal with conflicts:
    • Conveyor logic expects old timer structure
    • Recipe manager references tags that were renamed
    • Current master has communications updates neither old machine has
  9. Manually resolve conflicts and re-test
  10. Debug integration issues

Time: Days of work
Risk: High (untested combinations, divergent program versions)

The HMI Reality

Same problem, different platform. You have a "master" HMI project. Any changes require reverse engineering old projects and resynchronizing with a newer PLC program.

When you build Machine 47's HMI:

  • Customer needs badge login screens (last used on Machine 31)
  • Customer needs multi-language support (last used on Machine 38)

The process:

  1. Find Machine 31's HMI project (6 months old)
  2. Identify badge login screens and tag mappings
  3. Find Machine 38's HMI project (4 months old)
  4. Locate multi-language implementation
  5. Copy screens into current master
  6. Fix tag name references (changed since Machine 31)
  7. Fix navigation links (screen names changed since Machine 38)
  8. Debug integration conflicts
  9. Test and hope

Time: Days of work
Risk: High (same problem as PLC side)

What This Really Is

This is a manual attempt at modern version control. Machines diverge from the master over time without modern version control. And it costs you thousands of engineering hours per year.

You don't have:

  • Git based version control
  • Tagged releases
  • Visual historical updates
  • Change tracking
  • Rollback capability

You have:

  • Folder full of .ACD files named "Machine_31_Final_v2.ACD"
  • HMI projects in "Backup_2024_Jan_DO_NOT_USE" folders
  • "Current_Master" that isn't actually current
  • Tribal knowledge: "Machine 38 has the good recipe logic, but don't use its alarm setup"
  • Check in Check out version control with an accompanying word document

Why This Happens

Copy-Paste Culture

Engineers learn to work this way:

  • Find a similar machine
  • Copy the program/project
  • Modify for new customer
  • Archive when done

Management reinforces it:

  • "Just copy Machine 23, it's close enough"
  • "We don't have time to 'do it right', just get it working"
  • "Engineering budget: 40 hours" (so no time for architecture)

The result:

  • Every machine is slightly different
  • Knowledge is scattered across 50 archived projects
  • New engineers spend 6-12 months learning "where things live"
  • Bug fixes require updating 50 separate programs

The Path of Least Resistance

Automation platforms provide the building blocks for good architecture:

  • PLC platforms support reusable components (AOIs, FBs, UDTs)
  • Modern HMI platforms offer template systems
  • Version control tools are available

But the challenge is organizational:

  • Architecture requires upfront investment (easier to copy-paste now)
  • Version control requires discipline (easier to skip)
  • Template thinking requires training (easier to hard-code)
  • "We'll implement it right on the next project" (but timeline pressure repeats)

The tools exist. The gap is adopting the practices.

The Solution: Version Control + Reusable Components

Pillar 1: Modern Version Control

  • Git repository (GitHub, Bitbucket, GitLab, Azure DevOps)
  • One master branch (single source of truth)
  • Feature branches (when developing new capabilities)
  • Tagged releases (Machine_47_v1.0)
  • Commit history (who changed what and why)

Pillar 2: Reusable Components

  • PLC: AOIs, UDTs, parameter-driven logic
  • HMI: Templates, Types, parameterized faceplates
  • Configuration: CSV files, data tables, parameter objects
  • Documentation: Self-documenting code, standard naming

When combined: Architecture that scales to hundreds of machines.

Combined PLC + HMI Architecture

One configuration process. Two systems synchronized.

Most OEMs configure PLC and HMI separately. When they get out of sync (and they always do), you get:

  • HMI screens for equipment that doesn't exist
  • PLC logic running that operators can't see
  • Field techs configuring the same machine twice

Tethered architecture: Configure once. Both systems respond.

Architecture concepts apply universally. The specific platforms and tools vary, but the core principles (reusable components, parameterization, version control) work across all automation systems.

Example: Machine Configuration

PLC Side:

Machine_Config UDT:
  - Num_Conveyors (DINT)
  - Badge_Login_Enabled (BOOL)
  - Max_Speed (REAL)
  - Languages_Enabled[6] (BOOL array)
  
Startup Routine:
  - Read Config from HMI
  - Enable/disable PLC logic based on config
  - Initialize arrays based on counts

HMI Side:

Startup Configuration Screen:
  - Displays config options
  - Writes selections to PLC Config UDT
  - Enables/disables HMI screens
  - Sets visibility flags

Result:

  • Single configuration point (startup screen, or derived from CRM/ERP specifications)
  • PLC and HMI stay synchronized
  • Field tech configures both simultaneously
  • Engineer maintains templates only

Concrete Example: Option Enable/Disable

When properly tethered:

  • PLC: Conveyor AOI[3] enabled only if Machine_Config.Num_Conveyors >= 4
  • HMI: Conveyor_03 screen visible only if same condition
  • Startup screen: Tech selects "3 conveyors" → Both PLC logic and HMI screens adjust

Without tethering:

  • Enable conveyor in PLC
  • Separately enable screen in HMI
  • Forget one → commissioning issues

Version Control Implementation

The specific tool and process matter less than the discipline of using version control consistently.

Basic workflow:

  1. Establish a tethered (PLC+HMI) repository
  2. Collaborate on the shared project
  3. Automate documentation
  4. Leverage changes for Validation / QA

Benefits:

  • Track every change
  • Roll back bad changes
  • Safe collaboration
  • Clear history of what changed when
  • Find deployed versions instantly
  • Single source of truth
  • Track changes systematically
  • Automated specifications

Version Control + Lean Architecture

Leveraging a foundation of these two concepts optimizes development efforts. Click expand to see some scenarios.

Scenario 1: Feature Request

  • Customer calls: "We need conveyor accumulation logic like Machine 47 had"

Without version control + architecture:

  1. Find Machine 47's archived file (6 months old)
  2. Extract conveyor logic
  3. Merge into current template
  4. Hope it still works

With version control + architecture:

  1. Conveyor logic already exists in current template (it's an option)
  2. Enable it
  3. Done

The difference: Version control gave you confidence to build options into the template. Without VC, you're afraid to modify the master, so you copy instead.

Scenario 2: Bug Mitigation

  • Bug found in Recipe AOI after 30 machines deployed

Without version control:

  • "Uh... which machines have Recipe enabled? Maybe 20-30?"
  • Manually check each deployment
  • Miss some machines

With version control:

  • Check tagged releases: Machines deployed after v2.3.0 have the bug
  • Exactly 17 machines identified
  • Update plan created

The difference: Tagged releases track what went where.

Real-World ROI Calculation

Scenario: OEM Building 50 Machines Per Year

Current Approach:

Average: 115 hours × 50 machines = 5,750 hours/year

Machine programming hours:

  • Simple machine: 50 hours (copy master programs, basic modifications)
  • Standard machine: 110 hours (hunting old features, merging divergent code)
  • Complex machine: 220 hours (multiple feature merges, new feature additions, debugging integration)

New Approach:

Year 1 Total: (R&D + Training + New Processes) = 1,715 hours
Savings Year 1: 5,750 - 1,715 = 4,035 hours (70%)

Year 1:

  • Architecture design: 400 hours
    • Identify common equipment and screens
    • Build reusable components (AOIs, HMI templates)
    • Design unified configuration structure
    • Test PLC + HMI integration
  • Version control setup and training: 40 hours
  • Total investment: 440 hours

Machine Development:

  • Machine 1: 250 hours (develop within new architecture)
  • Machines 2-5: 50 hours avg (learning curve)
  • Machines 6-20: 25 hours avg (adoption phase)
  • Machines 21-50: 15 hours avg (mature architecture)

Year 1 Total: 440 + 250 + (4×50) + (15×25) + (30×15) = 1,715 hours
Savings Year 1: 5,750 - 1,715 = 4,035 hours (70%)

Year 2+ (Mature Architecture):

  • Most machines: 12-15 hours (configuration only)
  • New features: 40 hours to develop, then reuse
  • 3-5 new features per year typical

Year 2 Total: ~750 hours for 50 machines
Savings Year 2: 5,750 - 750 = 5,000 hours (87%)

Break-Even Analysis

Break-even: Machine 9-10

Investment: 440 hours upfront

By machine 50: Cumulative savings ~4,000 hours
By machine 100: Savings approach 8,000-10,000 hours

"At typical engineering rates ($100-150/hour), this represents $400,000-$600,000 in annual savings by Year 2."

Getting Started: The Practical Path

Phase 1: Assessment

Inventory your current approach:

  • How many machine variants do you build per year?
  • How much engineer time per machine?
  • What features get reused across machines?
  • Where is knowledge stored? (tribal knowledge vs. documented)
  • Do you have version control?

Calculate current costs:

  • Engineering hours × hourly rate
  • Rework time (bug fixes, integration issues)
  • Opportunity cost (projects delayed waiting for engineering)

Phase 2: Version Control Implementation

Why version control before architecture? Architecture evolves through iterations. Without version control tracking those changes from day one, you lose design decisions and make team collaboration difficult. Version control is the foundation you build architecture on.

Set up version control system:

  • Choose appropriate tool for your platforms
  • Configure project structure
  • Set up backup/redundancy

Train team:

  • Tool basics (check-in, tagging, comparing versions)
  • Workflow procedures
  • Documentation standards

Establish process:

  • Regular check-ins (daily minimum)
  • Release tagging (every deployed machine)
  • Change documentation (what and why)

Phase 3: Architecture Design

PLC Architecture:

  • Identify common equipment (pumps, motors, valves, conveyors)
  • Design AOI/FB library structure
  • Build parameter UDT structure
  • Create configuration framework

HMI Architecture:

  • Design template hierarchy
  • Identify reusable faceplates
  • Plan multi-language approach (if needed)
  • Design startup configuration screen

Integration:

  • Define PLC/HMI configuration handshake
  • Plan parameter synchronization
  • Document architecture decisions

Phase 4: Pilot Project

Choose appropriate pilot:

  • Not too simple (doesn't prove architecture)
  • Not too complex (avoid overwhelm)
  • Has 3-5 equipment types (pumps, valves, tanks)
  • Typical customer feature set

Build within new architecture:

  • Develop AOIs/templates
  • Test reusability
  • Validate configuration approach
  • Document lessons learned
  • Utilize Version Control to speed R&D
  • Automate the Startup Process

Expect: 50% longer than old approach (learning curve)

Phase 5: Scale

Build momentum:

  • Machines 2-5: Learn and refine
  • Machines 6-20: Prove ROI, gain confidence
  • Machines 21+: Reap benefits, continuous improvement

Continuously:

  • Add to AOI/template library when new equipment needed
  • Refactor old components as time permits
  • Document best practices
  • Train new engineers in architecture thinking

Common Objections (And Responses)

"This Sounds Like a Lot of Upfront Work"

It is. Machine 1 will take longer than your typical copy-paste approach.

But the math is clear: By machine 8-10, you're breaking even. By machine 50, you're dramatically ahead.

The real question: Do you want to keep hunting through old programs forever?

"Our Machines Are Too Custom for Templates"

Every OEM believes this. Then they realize:

  • 80% of machines share 80% of functionality
  • The 20% that's truly custom is where you should spend time
  • Not reimplementing pump control for the 50th time

Reality: Your machines are more similar than you think.

"We Don't Have Time to 'Do It Right'"

You don't have time not to do it right.

Current approach: 115 hours per machine

Architecture approach (mature): 8 hours PLC + 7 hours HMI = 15 hours per machine

You're spending 115 hours per machine to avoid spending 15 hours thinking about architecture.

"Management Won't Approve the Investment"

Show them the ROI calculation.

Investment: 480 hours
Break-even: Machine 8-10
Year 1 savings: 4,000+ hours
Year 2+ savings: 5,000+ hours per year

At $100/hour: $400,000+ saved annually (year 2+)

Ask management: Can we afford not to invest?

"Our Engineers Resist Change"

Bottom-up or Top-down

1. Bottom-up: Find engineer champions, prove success on pilot, let peers see results

2. Top-down: Management mandates architecture approach, provides training, enforces Git

Most successful: Combination of both.

Key: Show engineers this saves them time. They hate hunting old programs too.

Key Principles Summary

Architecture Fundamentals

  1. Version control is non-negotiable: Git or equivalent, properly implemented
  2. Reusable components over copy-paste: AOIs/FBs for PLC, Templates for HMI
  3. Parameterization over hard-coding: Configuration objects, parameter UDTs, CSV files, ERP integration
  4. Configuration over custom logic: Enable/disable features, don't rewrite
  5. PLC and HMI architecture align: Same configuration approach, synchronized
  6. Automate the Startup process: Field-selectable options, or automated parameterization
  7. Document as you build: Self-documenting code, standard naming, architecture guides

Process Fundamentals

  1. Invest in architecture and design before coding: Design phase is not optional
  2. Accept first project slowdown: Learning curve is temporary, benefits compound
  3. Test component combinations: Validate common scenarios before deployment
  4. Train the team: Architecture thinking > platform training
  5. Commit frequently, tag releases: Every deployed machine is tagged
  6. Continuous improvement: Add to library organically, refactor when beneficial
  7. Measure and communicate ROI: Track time savings, show management results

Conclusion

The Version Drift problem is universal:

  • Affects PLC and HMI development
  • Exists across all platforms
  • Costs thousands of engineering hours annually
  • Scales poorly, creates technical debt

The solution is proven:

  • Version control (Git or equivalent)
  • Reusable components (AOIs, templates, faceplates)
  • Parameterization and configuration over custom logic
  • Startup configuration screens for field deployment
  • Architectural discipline and team training

The ROI is undeniable:

  • Break-even: 8-10 machines
  • Year 1: 70%+ time savings
  • Year 2+: 85%+ time savings
  • Compounding benefits forever

The choice is yours:

  • Continue hunting old programs, merging divergent code, debugging integration issues
  • Or invest in architecture, implement modern version control, and build once/reuse forever

Most companies: Keep saying "we'll do it right next time"

Successful companies: Make the investment, prove the ROI, never look back

Which will you be?

Ready to Transform Your Development Process?

ASQI helps OEMs and system integrators implement template-driven architecture and version control practices that deliver 70%+ time savings.

Our Services:

  • Architecture design workshops
  • Version control implementation and training
  • Template development consulting
  • Team coaching and mentorship

Let's discuss your specific situation:

  • How many machines do you build per year?
  • What's your current development time per machine?
  • Where are you losing the most time?

Contact ASQI →

Or email directly: [email protected]

Development Best Practices for Optix — Apply these architecture principles with concrete coding patterns and project structure guidelines.

Building Reusable Popup Templates with Alias Passing — A worked example of the template-driven design discussed in this post.

Migration Strategies: Port, Redesign, or Hybrid? — How your architecture choices drive which migration strategy is viable.