Frequently Asked Questions
These are the questions clients ask before they contact us. The answers are written here — and where the answer is “we do not do that”, we say so.
Scope: what we do, and what we do not
Drawing the boundary first saves both sides a lot of back-and-forth.
Which PLC brands and models do you work with?
Mainly Siemens S7-1200 / S7-1500, delivered in SCL, LAD or FBD. We also take on upgrades of older hardware (S7-200 / S7-300 or third-party brands) — that falls under “Retrofit · diagnostics · program rescue”.
Do you do the program only, or electrical work as well?
Programs and verification only. Electrical design, component selection, switchgear assembly and site wiring are outside our scope. We draw the line there because our capability and our evidence both sit at the program layer, and electrical work is better handled by a dedicated panel builder.
What about functional safety — E-stops, safety doors, SIL/PL?
Safety logic inside the program can be implemented to your definition, but we do not sign off on functional safety (SIL/PL) — that must be done by a qualified party. In high-risk applications this is a hard requirement, and we will not blur it to make a contract easier to sign.
Delivery
What do you deliver? Do we get the source program?
The program itself (SCL / LAD / FBD) plus supporting documentation: I/O allocation table, POU structure description, the actual TIA Portal compile log, static analysis report, verification records, and a list of open items for site conditions not yet confirmed. The program follows your naming conventions and block structure.
Do you have to come on site, or can everything be done remotely?
Everything at the program layer — requirements analysis, development, static checks, simulation verification, logic audit, version comparison — can be done remotely. Wiring and hardware replacement, on-machine trace capture, independent verification of safety functions, and confirmation of physical phenomena must be done on site. We state clearly which parts require attendance instead of promising that remote solves everything.
We have not confirmed all site conditions yet. Can we start anyway?
Yes. Unconfirmed conditions are logged as open items, each stating the branch action for both “if yes” and “if no” before we proceed. Such conclusions are not valid as final acceptance evidence — once a condition is confirmed, the affected deliverables must be updated before the item is closed.
Will our programs leave the plant?
That depends on the delivery model. Under model ② (private deployment), the agent and the model run inside your intranet or an offline environment, so programs and drawings never leave, and we do not use your site data for training. Under model ① (human-in-the-loop), we deliver after our engineer reviews and signs off, with the required isolation and access conditions spelled out in the implementation plan.
Process and responsibility
Who is responsible if something turns out to be wrong?
Under model ① (human-in-the-loop), our engineer reviews and signs off, and the signer is responsible for the result. Under model ② (private deployment), the responsibility boundary, acceptance criteria and dispute handling are written into the implementation plan line by line before signing.
What exactly do you mean by “evidence”?
Compile logs, static analysis reports, simulation trace comparisons, state-transition and timer-timing verification records, and the open-items list. The rule is: missing evidence means failure — not “not checked”, and certainly not “passed by default”. And we keep three statements apart: static checks passing ≠ compiling ≠ the logic being correct.
Can static analysis find every problem?
No — and we say so up front. Mutation test results: syntax/structure-level defects are caught 6/6 by static analysis; semantic-level defects (such as changing an AND in a start condition to OR) are caught 0/6, while text similarity remains 0.9981. Semantic correctness is therefore the job of dynamic verification and human review — full details on the Evidence page.
How do we get started?
Three steps: ① send your requirements (process description, hardware model, I/O conditions, safety requirements, acceptance criteria); ② we assess feasibility and boundaries; ③ we quote against the assessed scope and proceed in stages. Contact details are on the Contact page.