If you are considering outsourcing PLC programming, you will soon face the same question: how much do I need to know up front for a service provider to make a serious offer? The short answer is that you do not need a finished specification, but you do need a clear idea of what the machine should do in the end, which hardware is already in place and how the result will be accepted.
The more precisely these points are described before you send your request, the fewer assumptions the provider has to make – and the smaller the risk margins, misunderstandings and change orders during the project. This guide shows which information has proven useful, which mistakes happen again and again, and how to recognize a service provider who takes your project seriously.
Goal and scope: what should be different in the end?
The starting point is not the technology but the goal. Is it a new machine that needs a control program for the first time? An existing line that is getting an additional station, a new product or another operating mode? Or the replacement of an old controller for which spare parts are hard to find and in-house knowledge has disappeared? Each of these projects comes with different effort and different risks – and therefore calls for different information.
Defining the boundaries is just as important. Describe what is explicitly part of the job and what is not. In PLC projects, the lines blur quickly: Is the HMI part of the order? Who does the electrical design, who builds the control cabinet, who wires the field devices, who procures the hardware? A phrase like “including everything that is needed” almost inevitably means that client and provider understand different things by it.
- Reason and goal in two or three sentences: new build, extension, modernization or troubleshooting
- What should measurably improve, such as cycle time, availability, usability or data collection
- What is in scope: control program, HMI, integration, commissioning, training
- What is explicitly out of scope or supplied by you or third parties
Machine description and functional specification
A provider who has never seen your machine first needs a picture of it. At the beginning, a short description is often enough: Which stations are there, how does material flow through the line, which drives, valves and sensors are involved? An overview diagram, a layout or a few photos and a short video of the machine in operation say more than many pages of text.
The core of every request is the functional description, often in the form of a requirements specification. It describes what the controller should do – not how it is programmed. This includes the normal sequence, operating modes such as automatic, manual and setup, the behavior during startup and shutdown and, above all, the behavior when faults occur. That last point is often forgotten, even though it usually takes more effort in the program than the fault-free sequence.
A complete specification is not mandatory for the request. What matters is that the available information is organized and that open points are clearly marked as open. The provider can then ask targeted questions or suggest clarifying these points together in an analysis phase at the start of the project, before any programming begins.
- Sequence in normal operation, step by step
- Operating modes and how to switch between them
- Behavior during faults, emergency stop and restart
- Recipes, product variants and parameters the operator is allowed to change
- Messages and alarms that should be displayed or passed on
Hardware, control platform and interfaces
If the hardware is already fixed, name the controller, programming environment and version as precisely as possible – for example TwinCAT 2 or TwinCAT 3, STEP 7 or TIA Portal, CODESYS 2 or CODESYS 3, Studio 5000. Add remote I/O, drives, operator panels and any special modules. An I/O list or the hardware configuration from the existing project saves a lot of back-and-forth.
If the platform is still open, say so explicitly and describe the constraints: plant standards, spare parts on hand, the platform your maintenance team is familiar with, or requirements from your end customer. These factors often decide the right choice more than technical details do.
Interfaces are at least as important. At the field level, this means bus systems such as PROFINET, EtherCAT, EtherNet/IP, Modbus or IO-Link. Further up, it means connecting to a SCADA system, MES, ERP or database, for example via OPC UA or MQTT. For each interface it should be clear which data flows in which direction, who is responsible for the other end and whether its specification is already available. In practice, interfaces to systems from other suppliers are one of the most common causes of delays during commissioning.
- Controller, programming software and version, plus any existing licenses
- I/O list, hardware configuration and wiring diagrams
- Fieldbuses and the devices connected to them
- Higher-level systems, required data points and the contact person for the other end
Existing code and documentation
For extensions and modernizations, the existing installation is the biggest unknown. Find out in advance whether the current control program is available as a project file with symbols and comments, or only as an upload from the running controller. Check whether any blocks are know-how protected and whether you have the rights and credentials needed to edit the program. A program without comments or with protected blocks can often still be reused, but it takes considerably more analysis time.
The same applies to documentation: wiring diagrams, operating manuals, parameter lists and notes from maintenance. If you know that the documents no longer match the actual state of the machine, say so. That is not a flaw – with older equipment it is more the rule than the exception. What matters is that it can be taken into account in the quote.
When modernizing older controllers, for example migrating from S5 or STEP 7 to a current platform, the existing state should be documented first. That way nothing that works today gets lost during the retrofit – not even the small special functions that were added at some point and are not described anywhere.
- Project file with comments, or only an upload from the controller?
- Date of the last backup and any changes made since
- Protected blocks, credentials and usage rights
- How current the wiring diagrams and operating manuals are
Clarify safety requirements early
Safety functions such as emergency stop, guard door monitoring or safely limited speed affect hardware, program structure and commissioning. They cannot be added at the end of a project without shifting effort and deadlines. Before sending your request, find out whether a risk assessment exists, which safety functions result from it and who is responsible for defining and verifying them.
What the provider mainly needs to know is whether a safety controller or safety relays are in place, whether safety-related program parts are part of the job and which requirements apply to them. Which requirements must be met in a specific case is a question for your safety experts and, where necessary, your legal counsel. This guide cannot and does not intend to replace that – it is only meant to point out that the topic belongs at the beginning, not at the end.
Acceptance, commissioning, handover and schedule
Define how you will know that the job has been done. Good acceptance criteria can be tested: a specific cycle time, a defined sequence running without faults for a set period, the correct response to simulated errors, the complete transfer of certain data to the higher-level system. Whether there is an earlier test in the office, in the workshop or on a test bench, and how acceptance under real conditions on the machine will take place, also belongs in the request.
For on-site commissioning, the provider needs realistic information: When will the machine be mechanically and electrically complete? Is there a downtime window for the changeover, for example over a weekend or during a plant shutdown? Which access rules, safety briefings and contacts apply on site? Is material available for test runs? You can find more on preparation in our guide to PLC commissioning.
The handover should also be settled in advance: Which documentation do you expect, in which language and format? Will you receive the commented source project? Should your operating and maintenance staff be trained? And what happens after go-live – support, maintenance or further development?
When it comes to the schedule, it helps to distinguish between firm and flexible dates. A contractually agreed delivery date to your end customer or a planned production start is something different from a preferred date. Also state by when you need the quote and when you plan to decide.
- Testable acceptance criteria and the acceptance procedure
- Dates for mechanical completion, downtime window and production start
- Expected documentation, source project and training
- Support after go-live
Common mistakes – and what a good provider asks back
Many requests do not fail because of the technology but because of a few recurring patterns. The scope is described only as a keyword, such as “replace the controls on line 3”, so every supplier quotes something different and the offers cannot be compared. Fault behavior is missing from the functional description. The condition of the existing installation is judged too optimistically. Interfaces to other suppliers are dismissed as “standard”. And commissioning is planned so tightly that there is no room left for testing and optimization.
How a provider responds to your request is also revealing. A quote that arrives without a single question is based either on very complete documents or on assumptions you do not know about. A good provider asks targeted questions, states its assumptions in the quote and is open about which points it can only assess reliably after an analysis. Typical questions are:
- Is the current program available as a project file with comments, and has it been changed since the last backup?
- Who is responsible for the other end of each interface, and is there a specification for it?
- How should the machine behave during faults, power failure and restart?
- Which safety functions exist, and are safety-related program parts part of the job?
- How will acceptance be measured, and who signs it off?
- How long is the downtime window, and what happens if it is not enough?
- Who will operate and maintain the machine later, and which platform is your team familiar with?