Skip to main content
Axiotech Automation Ltd
+44 (0)7415 112 892
sales@axiotech.co.uk

Requirements · design · modules · interfaces

Create software documentation that helps engineers control the system—not paperwork disconnected from the source.

Axiotech develops proportionate URS input, functional and system design, software/module design, interface and configuration records around the real architecture, terminology and responsibilities of the control system.

Scope this requirement See all validation & compliance

Good fit

Use this service when

  • TwinCAT, PLC/HMI, motion, machine-data and engineering software requiring maintainable design evidence.
  • New delivery or evidence remediation where competent technical access and reviewer authority are available.

Scope boundary

Not assumed or silently included

  • Copying source code into a document and presenting it as design rationale.
  • Retrospectively asserting requirements or approvals that cannot be supported by available evidence and authorised review.

Why act

The operational risk behind the technical symptom

The first work package is shaped around reducing an explicit risk or enabling a named decision.

01

Ambiguous requirements allow different stakeholders to accept different systems.

02

Design knowledge remains trapped in code structures, naming and engineer memory.

03

Documents and released software diverge because they do not share version and change control.

Purchasable entry points

Choose a bounded engagement before expanding scope

Final inclusions, dependencies, location, schedule and commercial terms are confirmed in a formal quotation.

Package 1

Documentation architecture

Decision enabled: A proportionate document map, ownership model and terminology baseline.

Typical scope: Intended readers, existing records, architecture, risk, templates, review and maintenance plan.

Package 2

Design-document work package

Decision enabled: Reviewable requirements and design records for an agreed system boundary.

Typical scope: Workshops, source/design analysis, drafts, technical review, trace links and approved issue.

Package 3

Documentation remediation

Decision enabled: An honest current-state evidence set with gaps and limitations visible.

Typical scope: Evidence inventory, code/configuration inspection, interviews, reconstruction, review and gap disposition.

Artefact manifest

What remains after the engineering work

The exact document set scales with risk and the approved work package.

  • Document plan, glossary and responsibility matrix
  • User/functional requirement inputs and acceptance criteria
  • System/software architecture and detailed module design
  • Interface, data, I/O and configuration specifications
  • Review comments, approvals, revision and source cross-references

Technical and responsibility boundaries

Make ownership reviewable

  • Document purpose, audience, approval and maintenance owner are defined before drafting.
  • Retrospective records distinguish observed implementation from approved design intent.
  • Customer templates and procedures govern where required; Axiotech does not silently replace them.

Review and acceptance

Six gates from authority to handover

Gate depth changes with the work; named decisions and evidence remain.

  1. G0
    Scope authorityOutcome, boundaries, roles, assumptions and commercial basis agreed.
  2. G1
    Baseline acceptedKnown installed/source state, dependencies, constraints and unknowns recorded.
  3. G2
    Design approvedRequirements, interfaces, risks and acceptance evidence ready for implementation.
  4. G3
    Release candidateBuild reviewed, verified, versioned and accompanied by defect disposition.
  5. G4
    Site acceptanceCommissioning evidence, deviations and release decision recorded.
  6. G5
    Handover acceptedSource, configuration, records, recovery and residual risks transferred.

Read the complete delivery method

Assurance option

Compliance is a declared scope—not a badge

Documentation supports assurance only when it is accurate, reviewed, controlled and used. Titles such as SDS or SMDS do not confer compliance; content and lifecycle must fit risk, architecture and the customer quality system.

Review validation services

Relevant engineering evidence

PLC software design-document hierarchy

A scalable document model separating system architecture, software design, module contracts, interfaces and configuration from source-level implementation detail.

Review this evidence

Procurement FAQ

Questions to resolve before quotation

Can you use our document templates?

Yes. Content, terminology, review states and traceability are mapped to the customer document-control process.

Can documentation be created retrospectively?

Yes, with care. Observed facts, inferred intent, unresolved gaps and newly approved requirements must remain distinguishable.

How detailed should module design be?

Detailed enough to review responsibilities, states, interfaces, critical logic, failure behaviour and maintenance decisions without duplicating every code statement.

Next decision

Describe the outcome, installed baseline and constraints you already know.

Use “Not known” where evidence is missing. The first review will separate facts, assumptions and discovery work.

Scope Automation software documentation