AI and automation in mechanical engineering

The answer depends on the task, not the vendor. Costing, documentation and service reports are about text and experience, and that is where language modelsLLMA large language model that understands and generates text, forming the technical basis of modern AI assistants. play to their strength. For measurement series from the machine, classical analysis or a purpose-trained method is often more accurate. We settle first which question you want answered. The technology follows from that.

That actually makes the start easier, because it works from your own records: costing, documentation and service documents draw on your own project folders, the ERPERPThe central system for commercial operations — orders, stock, pricing, invoices. Usually the authoritative source for numbers in the business. and the service reports. Where data from a machine at a customer site should come in later, the first question is not the technology but the clearance. Who owns the data, what may your company see, what stays with the customer. That belongs in writing before anything is connected, and ideally in your delivery and service terms rather than in a later conversation.

It splits by whether you produce in series or build one-offs. If you produce in series, it pays where enough timestamped measurement data exists: catching deviations earlier instead of seeing them at final inspection, condensing maintenance free text into comparable fault patterns, pre-sorting inspection images. In production planning the usable methods are then mostly not language modelsLLMA large language model that understands and generates text, forming the technical basis of modern AI assistants. but optimization: sequencing, reducing changeover times, balancing capacity. In special-purpose machine building with a batch size of one, the benefit sits elsewhere, namely in costing, documentation, commissioning and service. The entry point is the same either way: one process, one question, one result your people can judge.

In most cases yes, and I do not expect anything else. Costings, time records and post-calculations are scattered almost everywhere: in the ERPERPThe central system for commercial operations — orders, stock, pricing, invoices. Usually the authoritative source for numbers in the business., in project folders, in spreadsheets that grew over the years, sometimes on a network drive nobody has tidied in ages. That is effort in opening it up, but not a disqualifier. More important than the format is whether the old figures are actually true — whether what a machine really cost in the end was recorded, and not just what was quoted. That is exactly what we look at together before anything gets built.

In stages. Each is estimated and quoted on its own, and the first is usually a single process, the costing aid or the documentation. You commission only the next stage, get a result that is useful on its own, and then decide further. Because the work recurs daily, the first stage has typically paid for itself within a few months. The initial conversation costs you nothing but time and can end with me advising against it.

A fair question, and your co-owner will ask it too. What gets built sits in your own code archive: documented, with automated tests, with an installation that can be repeated. Your systems house or another provider can build on it. On larger undertakings I work with your team or with established partners anyway. And because the first step stays small, you judge me on a finished result before anything important depends on it.

Yes, and in mechanical engineering that is often the only acceptable option. Capture, analysis and even a self-hostedself-hostedThe solution runs under your own control or in infrastructure you choose rather than exclusively with the provider. language model run entirely inside your network, behind the separation between production and office IT, with no outbound connection. That largely defuses data protection: what never leaves your plant is processed by nobody outside it. Machine data rarely carries personal data anyway; service reports with names do, and we treat those fields separately. What a local AI depends on more is the hardware: how many concurrent users, on which machine. How many people will work with it and how fast a response has to be is something we settle together. From that follows which machine suffices and what it costs once.

That is the normal case, not the obstacle. At Sartorius the legacy systems had to keep working while the data flowed into modern processing. In a corporate project no source code existed for some of the tools, and they were connected regardless. Whether an old application stays connected or is better replaced with something new is your decision. Connecting gets you to a first result faster; replacing pays off once maintenance and workarounds cost more than a rebuild. I build either, and which one works out cheaper for you we calculate beforehand.

Then what remains is analyzing the communication and going in through whatever routes the system does expose. I have had that task several times in industrial projects. Legally the position is better than many assume: a lawful user may observe and test a program (§ 69d(3) German Copyright Act) and, within narrow limits, decompile it where that is indispensable for interoperability with their own software (§ 69e). Neither right can be validly excluded by contract (§ 69g(2)). The limits are narrow, so we look at the specific case. What remains to check is your warranty: technically possible and contractually clean are two questions.

Sometimes. The condition is a hard one: your history has to contain enough documented failures, otherwise a prediction cannot be validated at all. Many operations do not have that data yet. Then capturing it systematically is the first step, and it pays off even without prediction.

Not without your explicit decision. The normal case is reading only: capture data, analyze it, display it. The route out of the production network runs through a clear boundary, and a writing path back is not part of it. If the people responsible for machine safety require a strict one-way street, they get one.

That is a question of architecture. At Advastore it was coordinating autonomous robot fleets under time pressure: path planning and job assignment were optimized, on unchanged hardware. Worth being precise, because the word means something else in this industry: that is the coordination layer in the millisecond range. Hard real time with a guaranteed cycle stays in the controller, which is where it belongs.

It depends on the use. Analyzing and displaying process data is uncritical. As soon as a system influences a safety-related function of your machine it becomes a safety component. Then the AI Act and the Machinery Regulation (EU) 2023/1230, applicable from 20 January 2027, apply together, and self-declaration can turn into involving a notified body. That is why such functions stay out of scope; it keeps your CE conformity where it is today. The binding classification is made within your conformity assessment.

Yes, and usually I have to. Processes and machine data cannot be judged from a screenshot. The first meeting happens at your site, with the people who know the machines and the costing.