What six chemical operators ask of a round-walking robot — and what of that is not on the datasheet

The names under the paper are not association officials. Peter Welter, responsible for automation at BASF, has publicly commented on the trial of a four-legged inspection robot in Ludwigshafen, whose manufacturer reports missions in the steam cracker and the oxo plant; Uwe Piechottka has had a legged robot inspecting a pilot plant at Evonik since January 2022 and told the trade press that the solution had shown mobile robots can perform inspection tasks consistently and deliver reliable information. Yanick Kleppinger works at Merck in Darmstadt, where a legged robot inspects an air purification system.

So the paper is not an industry's wish list but the record of people who had the pilot behind them and knew where it fell short of regular operation. NAMUR classifies it accordingly: a working-group position reflects the experience of the group's members, is agreed within the group, but does “not have the consensus status of a NAMUR recommendation”. Its purpose is to make experience available “promptly”.

For an operator procuring in 2026 that is the right degree of authority. A standard says what is permissible. This paper says what six colleagues missed after the first year.

The operators first describe what is to be replaced, and the description is unspectacular: besides the major inspections of pressure vessels and reactors, “less elaborate checks take place mostly several times a day as part of rounds”, carried out by a shift worker “who checks the plant using their senses and according to a checklist”. If something is found, plant management is informed.

The robot is to protect that worker from heat, noise, poor ergonomics, atmosphere and entering confined spaces, and free their labour for “more profitable work”. And it is to do something the person with the checklist does not: systematically build a body of data in which changes can be spotted early.

Then comes the list of what a round-walking robot can actually take over, and it is broader than the usual narrowing to reading gauges suggests:

• vessel inspection, for instance leak detection
• barrier inspection, specifically the inspection of tank bunds
• creating a 3D model of the plant
• heat maps for detecting gas concentrations
• safety and hygiene rounds — fire extinguishers, emergency exits
• determining progress and monitoring construction sites
• gas detection and gas mapping
• acoustic monitoring, vibration checks

The authors also name plant security at the site perimeter and the fire brigade in emergencies as further possible users of the same platform. Anyone who procures the robot only for gauges is buying it for one item on a list of nine — and pricing it too high accordingly.

Of the nine requirement sections, one is worded so as to exclude part of the market, and it sits under the unassuming heading of data security. “Data sovereignty must lie with the company that collects and evaluates the data for the applications.” And further: it is to hold “regardless of the storage medium (cloud, company-owned server, etc.)”, for data transfer as much as for storage.

The sentence is written against a business model, not a technology. A robot whose inspection data sits in the manufacturer's platform and is evaluated there meets it only if the operator can get that data out completely at any time. Which is why the second half of the same demand appears in the payload section: access to raw and inspection data is to be “provided by the manufacturer via an Application Programming Interface (API)”, the data is to be available to the user “in a pre-interpreted form”, and the associated meta and raw data is to be retained for later use.

That is precisely the distinction that counts in operation. The pre-interpreted form is what the shift worker sees in the morning: gauge 4 reads 6.2 bar, bund 7 dry. The raw data — the image, the thermal image, the audio recording, the timestamp, the position — is what will be needed in three years when someone asks since when the value has been drifting. A system that supplies only the first layer does not build the “treasure of data” from the introduction. It builds a log.

The question to the manufacturer thereafter is not “do you have an API” but: does it give me the image behind the reading, and can I export everything if I terminate the contract?

The section on service life and repair is short, and every line in it is a contract clause.

First: the lifecycle of non-safety-relevant components is to be designed “so that operation of the robot amounts to at least 5 years”. Five years is a short horizon in chemicals and a long one in mobile robotics; which components carry that horizon and which do not is therefore not a question to the manufacturer in general but to the compute module, the battery and the sensors individually. What a published end date for a compute module means for the contract term is the subject of its own article.

Second: “The compatibility of subsystems of different generations should be ensured across several device generations.” Anyone procuring a payload today wants to mount it on the next generation of robot. That is a demand on the interface, and it is why the authors require in the payload section a “uniformly defined interface” over which sensors can be swapped “after a one-off integration effort” at little cost.

Third: response times for fault fixes that cannot be done on site, and the necessary spare parts, “should be governed by a service contract”. Faults may be fixed by regulated remote access, but the stated aim is to have “local contacts”. What an update process looks like that the operator has to agree with the manufacturer itself because nobody prescribes it is described in the article on software updates; the NAMUR authors are asking in essence for the same contract.

Three sections of the paper treat the robot as what it is after the pilot: one more networked device on the plant site, with the same obligations as any other.

Connection. The physical network connection “should be designed via company-internal WiFi or 4G or 5G structures”. What happens on connection problems, loss of connection or unauthorised access is to be assessed and mitigated. For procurement that means: a robot that brings its own radio infrastructure is not automatically an advantage. It is a second network the IT department does not know.

Control. It is to be implemented “intuitively and in a task- and rights-based access model” — across the whole lifecycle.

Access. The authors require user management with roles and rights and note: “Ideally, a connection to existing user management systems is possible.” That is the line on which a site with two hundred shift workers and a robot that keeps its own accounts can founder. Who may take over the round, who may change missions and who only sees results should come from the directory the site maintains anyway.

None of this is specific to robotics. These are the requirements for any device that joins a site network, and the authors say as much in substance: the information-security requirements that apply to the robot's operating environment must be met by the robot as well. The pilot was allowed to be an exception. Regular operation is not.

The fourth section contains the sentence every operator should know before ordering: robots “out-of-the-box” are in many cases described as incomplete machines “that are only completed through an integration effort”. In the authors' account the system becomes operable only from four building blocks: application, software, hardware and protective measures.

That shifts the question of who actually delivers. On this understanding the platform manufacturer is not the party bringing the operable machine into the plant. That is the integrator — and the authors note that this role “can equally be taken by the manufacturer itself, a supplier or the operator”. Whoever designs the application and is responsible for the protective measures and the control interfaces carries the role. An operator who fits the robot into its own plant is thereby its own integrator, with everything that entails.

On the operator side the authors recommend involving the specialist departments for machine safety, occupational safety and data security “as well as the works council as early as possible in the procurement and application design process”. And they give a piece of advice that comes from experience with the second robot: lay out the risk-assessment documents so that they are “reusable and easily adaptable for later applications”, with a global collection of hazards and protective measures. Anyone who writes a document for the first route that applies only to the first route writes it again for the second.

Three caveats, because the text names its own reach.

It is a position, not a consensus. NAMUR says so in the document's header: the working-group position reflects the experience of the group's members and does not have the consensus status of a recommendation or a worksheet. For an operator it is therefore a checklist, not a proof. Anyone who puts it to a manufacturer is demanding answers, not conformity.

It dates from January 2023. The authors write that the use of autonomously walking or flying platforms for inspection purposes in the chemical industry is “at present still an absolute novelty”. Three and a half years later there are more references, and individual demands — the API, the user management — have become standard with some suppliers. The list remains the right order of questions all the same; only the answers have improved.

What is missing here is missing on purpose. The paper contains sections on safety and on the legal framework that this article does not reproduce. They are indispensable for a procurement in plants with special ambient conditions, and they are dealt with elsewhere. The point of this text is a different one: the paragraphs that decide operation after the pilot are those on data, service life, network and responsibility — and none of them is on a certificate.