Brownfield and greenfield code development

Your standard.
Clean code. Proven.

PLC and SCADA software for new plants and old ones, written the way you want it.

Sound familiar?

Code that works, but nobody can follow

Control software outlives the people who write it. On an existing plant it is often patched by several hands, lightly documented and risky to touch. On a new one, every supplier brings its own style, and you inherit the mix. Either way, the code has to run your process safely and stay supportable for decades.

The problemSpaghetti code
The fixMapped and documentedExisting code analysed first; every change made under control.
The problemSuppliers ignore your standard
The fixWe write to itYour blocks, your naming, your rules. Or ours.
The problemFaults found at commissioning
The fixProven in simulationSequences and interlocks tested before factory acceptance.
The problemDocuments that drift
The fixDocuments that matchI/O, alarm and cause-and-effect lists from the code itself.

How it works

Two starting points, one standard of evidence

We write to the standard you choose: yours, ours, or one we build with you. Existing code is analysed and documented before anything changes. New code is built from your specification. Both are version-controlled from the first line, tested against a simulated plant, and handed over with the documents and support your team needs.

Two starting points, one standard of evidence

What we do

Six ways we develop your software

Whether we extend a running plant or start from a blank page, you choose the standard the code is written to and how it is produced.

Option 03

A standard built with you

We create a standard with you: structure, naming, block library, templates and coding rules, documented so every future supplier and engineer follows it too.

Industries: Building Services

Option 04

Generated from your examples

Give us one well-written example of a motor, valve or sequence. We generate the rest of the project in the same form, so code is consistent and quicker to review.

Industries: Automotive, Baggage Handling, Food and Beverage, Warehousing

Mix and match

Most projects combine options

An extension to a running line usually keeps your blocks and the structure already there. A new line beside it can be generated from your examples, so the two look and behave alike. We agree the mix at specification stage and record it in the software design specification.

Industries

Industries we do this for

An ISO 9001 certified quality system, designing to the standards your sector demands, plus any you specify.

Water and utilities
Process
Manufacturing
Transport and logistics
Buildings and nuclear

How we deliver

From requirement to supported system

Development is one part of the job. Testing, commissioning, documentation and support come with it as standard.

  1. Specify

    Requirements, standards and risks agreed with you; on existing plant, the code analysed and documented first.

  2. Standardise

    The coding standard, block library and templates fixed before development starts.

  3. Develop

    Code written or generated to that standard, version-controlled and peer reviewed as it grows.

  4. Test

    Sequences, interlocks, alarms and faults tested against a simulated plant, then factory acceptance testing.

  5. Commission

    Installation, commissioning and site acceptance testing, planned around your operation.

  6. Support

    Documentation, training and long-term support, with 24/7 cover under a support agreement.

In full

The detail

Two starting points, one discipline

Most projects mix the two: new equipment on an existing plant, or a new line that must match the old one. The approach changes with the starting point; the standard of evidence does not.

Brownfield: an existing plant

The software is running and production depends on it. We change it without disturbing what works.

  • A restorable backup of what runs today, taken before anything changes
  • Code analysed and I/O, alarm and cause-and-effect lists recovered from it
  • Changes written in the style and structure already there
  • Each change tested in simulation against today's behaviour
  • Cut-over planned around your outages, with a rollback plan

Greenfield: a new system

Nothing exists yet. We get the structure right from the start, so the system stays supportable for its whole life.

  • Functional design specification agreed before code is written
  • Standard chosen up front: yours, ours or a new one
  • Consistent code generated from the plant's equipment list
  • Software proven against a simulated plant from the first build
  • Full document set produced alongside the code, not after it
What we develop
AreaWhat we developHow it is proven
PLC softwareIEC 61131-3 code in ladder, function block diagram and structured text; statement list where the existing program uses itCompiled clean, reviewed, sequence and interlock tests
Safety programsSafety functions on safety PLCs and relays, written to your safety requirements specificationSafety requirements tests, independently reviewed
HMI and SCADAScreens, alarms, trends, reports and operator commands, consistent with the PLC structureTested against the PLC running in simulation
Drives and devicesDrive, instrument, vision and robot interfaces, with parameters archived with the projectInterface tests and parameter records
Communications and dataPROFINET, EtherNet/IP, Modbus and OPC UA links, historians, reports and MES or ERP interfacesPoint-by-point communications tests
Version controlEvery change committed with its reason, reviewed and traceable from the first line to handoverChange history handed over with the source
Software that checks and builds software
Code analysis

Maps the blocks, sequences, loops, I/O and alarms of a TIA Portal project before we change it.

Document recovery

Produces I/O, alarm and cause-and-effect lists and a functional description from the code.

Code generation

Builds I/O mapping, state machines, alarms and loops from an equipment list.

Compile checks

Each change is imported and compiled automatically before an engineer reviews it.

Simulation

Programs run in PLCSIM Advanced with simulated inputs and process models.

Version control

Every PLC has its own repository; every change is reviewed before merging.

How we prove it, and where the line is
  • Every function traced from the specification to its code and its test
  • Code reviewed by an engineer who did not write it
  • Sequence, interlock and alarm tests run against a simulated plant before factory acceptance
  • Deviations logged with their fix and retest; nothing closed silently
  • On running plant, every change staged from offline to simulation to live, each step signed off
Simulation proves logic against a model of your plant, within that model. It never replaces tests on the real equipment, and it is never safety acceptance. Process limits and safety targets come from your process design and hazard studies; we implement, test and record them.
Software and the documents that explain it
  • Functional design specification
  • Software design specification
  • Coding standard and block library
  • I/O list and cause-and-effect
  • Alarm list and HMI interface
  • FAT and SAT protocols and records
  • Source code with its change history
  • As-built drawings and evidence index
  • Training and fault method statements

FAQ

Quick answers

Will you use our standard?

Yes. If you have a coding standard or block library, we write to it. If you do not, we offer ours or build one with you.

Our code is undocumented. Can you still work on it?

Yes. We analyse it first and recover the I/O list, alarm list, cause-and-effect and a functional description.

Who owns the software?

You do. You receive the source, its history and the documents, so you can support it yourself or with any supplier.

Contact

Talk to us about your software

Standards-led, fully documented control systems that you own and can support.