Machine Software Development 2026 | Five Layers That Change Scope and Cost

We would like to outsource the software development for a machine, so roughly what does that cost? I have never once been able to answer that question with a figure. The reason is that the software sitting on a machine is never a single thing. Sequence, motion, vision, the operator screen, and the handover to systems above the machine. Those five demand different skills, they are built by different kinds of companies, and they change at different rates. The moment they are collapsed into one line in a quotation that reads “control software, complete”, neither comparison nor acceptance testing works any more. This article splits machine software into five layers and sets out where responsibility divides and where the cost actually lands.

Why a machine software quotation never fits on one page

Before anything else, it is worth being explicit about why ordering software as a single undivided package causes trouble later. Skip this part and everything that follows looks like classification for its own sake.

A single line reading “control software, complete” is a quotation you cannot compare

Quotations received during a machine enquiry often carry exactly one line for software cost. The competing quotations carry one line as well. Line the figures up and it feels like a comparison has taken place, when in reality nothing has been compared at all.

Inside that one line, one supplier has priced sequence control only, another has priced the development of image judgement as well, and a third has included transmitting data to the systems above the machine. Put items of different scope side by side as money, and the narrowest scope always looks the most attractive. Then, towards the end of commissioning, everything that was not included arrives as a supplementary quotation.

This structure is common to automation quotations generally, and the discipline of normalising scope before comparing figures is covered in our article on comparing automation quotations. What follows here narrows in on software, the part of the scope that is hardest of all to see.

The scope machine software covers keeps widening

A survey published in May 2026, covering 120 decision makers at machine and equipment builders across 22 machine sub-industries in three regions, reported that 96% had begun applying AI in some form, whether to internal work or to the software on their machines. Within that, 55% had taken a specific use case all the way into production deployment, and 41% were at the proof of concept stage.

By use case, predictive maintenance in the production phase was reported at 54% and image recognition at 35%, while remote diagnostics in the service phase was reported at 48%.

The point to take from these figures is not that you ought to be adding AI. It is the direction of travel. The software that ships with a machine is no longer confined to the program that makes the mechanism move. Put remote diagnostics on a machine and you need a communications and logging design. Put image recognition on it and somebody has to own the judgement criteria and the consequences of getting them wrong.

The same survey lists the barriers to adoption as cost at 54%, insufficient data infrastructure at 43%, and a shortfall in people with the right skills at 43%. That data infrastructure and skills sit level with each other near the top is the mirror image of a simple fact. Ordering machine software is no longer a matter of having it built and then walking away.

Without splitting it, you cannot decide what to keep in house either

While the scope stays invisible, the line between in-house work and outsourced work cannot be drawn either. The parts of the machine software that your own engineers should be able to touch, and the parts that can safely be left to a specialist, are plainly not the same parts. Order the lot as one package, however, and that distinction cannot be created after the fact.

So this article divides machine software into five layers. The purpose of the division is not to split the order between several suppliers. It is so that even when a single supplier takes the whole job, deliverables and responsibilities can be written out layer by layer.

Splitting the software on a machine into five layers

The same phrase, machine software, covers a set of five different kinds of software with genuinely different characters. Here they are in order.

Layer 1 Sequence control – deciding the order in which the machine moves

Written in ladder or structured text on a PLC, this is the movement order of the machine itself. Read the sensor inputs, switch the outputs to cylinders and motors, and use interlocks to forbid dangerous combinations. This is the layer most people picture when they hear the words machine software.

Its defining features are that the thinking carries over even when the machine changes, and that maintenance staff find it the easiest layer to touch. On the other hand, it is also the layer where individual style shows through most strongly. Even when a program follows IEC 61131-3, the international standard for programming languages, that does not mean it can be moved across to another manufacturer’s PLC as it stands. The practicalities of ordering this layer are covered in detail in our article on outsourcing PLC program development.

Layer 2 Motion control – deciding how the movement is performed

Where a servo motor drives an axis, if layer 1 decides where to move to, layer 2 decides at what speed and acceleration, and along which path. Single axis positioning alone can be folded into layer 1 without anything breaking. Introduce synchronised multi-axis movement, cam profiles, or control of the force with which a part is pressed home, and it becomes an entirely different discipline.

What makes this layer awkward is that the requirement is hard to write down as a number. Adjustments phrased as “a little smoother” or “a little faster” surface during commissioning on the shop floor, and who carries the effort for that tuning tends to be left vague at quotation stage. If takt time is going to sit in the contract, then the conditions under which that takt is measured need to be written out explicitly as a layer 2 requirement.

Layer 3 Vision and measurement – deciding pass or fail

This is the part that takes an image and judges good from bad. In recent years machine learning has increasingly entered this layer. Judgement thresholds, lighting conditions, imaging position, and how the machine behaves when a judgement is wrong are all design objects here.

What separates layer 3 decisively from the others is that the correct answer does not live inside the machine. Layers 1 and 2 can be accepted on the basis of whether the machine did what it was told. Layer 3 cannot be accepted at all until somebody has decided whether the judgement itself is right. Whether the buyer or the machine builder owns that judgement criterion moves both cost and schedule substantially. The cost structure of building vision into a machine is set out in our article on the cost and payback of robot vision.

Layer 4 HMI and operator screens – where people meet the machine

The screens shown on the touch panel, the way alarms are raised, and the design of operating permissions. Once the machine is finished, this is the layer that the largest number of people touch every single day, and yet it is also the layer treated most lightly in the quotation.

At an overseas site, further conditions pile on. Which display language to use, who gets which permission, and whether local maintenance staff can understand the wording of an alarm. Layer 4 is frequently priced as screen drawing effort alone, when what actually determines the cost is the information design behind the screens. This layer is treated on its own in our article on designing HMI touch panel screens.

Layer 5 Upper system integration – what leaves the machine

Production counts, running state, changeover recipes, and traceability data. This is the part that hands those out beyond the machine. The destination may be a PC application, or it may be an MES or an IoT platform.

Layer 5 is the layer most likely to be cut with the words “we do not need that this time”. Adding it later, however, means going back into the layer 1 program, and once a machine is in production that is a difficult thing to touch. This is exactly why the decision to build only the collection point still pays. The thinking on the collection side is organised in our article on collecting data from PLCs.

The five layers side by side

What the table is saying is that the measuring stick for acceptance differs by layer. Under the same label of machine software, layer 1 is accepted on movement, layer 3 on judgement criteria, layer 4 on shop floor operation, and layer 5 on the requirements of whatever receives the data. A one line quotation flattens all five of those measuring sticks into one.

Machine software quotations diverge at the joints between layers

The joints between layers cause more trouble than the contents of the layers themselves. Where machine software development quotations differ from supplier to supplier, the difference is concentrated almost entirely here. Four boundaries are the usual suspects.

Boundary 1 Between sequence and motion – who decides the path

Where the specification says only that a workpiece is conveyed from A to B, there is no way to read out whether motion design is included. The machine builder reads it as moving to the coordinates it is given, while the buyer reads it as having an optimal path designed for them. That gap in interpretation surfaces as a takt shortfall at the end of commissioning.

The way around it is to fix the conditions under which takt is measured, and to fix them first. With which workpiece, over how many consecutive pieces, and starting from which state. Write that down and responsibility for path design moves naturally to the machine builder.

Boundary 2 Between vision and judgement – who owns the definition of a defect

When image judgement is in scope, the item that moves cost the most is who supplies the limit samples. Whether the buyer can physically present samples that sit on the border between acceptable and unacceptable. Order without them and the machine builder will provisionally set a criterion, build to it, and then rebuild it during commissioning.

The second thing to settle is how the machine behaves when a judgement is wrong. Does it stop, does it divert only the suspect items to a separate line, or does it record and carry on? That is an operational decision rather than a technical one, and only the buyer can make it.

Boundary 3 Between the HMI and operation – who designs the screen

The screens are generally built by the machine builder, but what is displayed on them is properly the buyer’s requirement. Leave that blank in the order and the machine builder’s standard screen set is delivered as is, leaving the shop floor operating a screen written in somebody else’s language every day.

What you keep in house is not the screen drawing itself. It is the list of information that has to be visible and the classification of alarms. Hand those two over and the drawing can quite reasonably be outsourced.

Boundary 4 Between upper integration and data – where the granularity is decided

The granularity of the data that leaves the machine cannot be decided by the machine side alone. Retain a record per shot, or aggregate by lot? Which clock provides the timestamp? How finely are the reasons for an abnormal stop to be classified?

Place an order asking for the machine to be made capable of producing data while that granularity is unresolved, and the result is data that the receiving system cannot use. If requirements above the machine are not yet fixed, the sensible middle position to write into the specification is that the granularity may be decided later, but the state of being able to collect it has to exist now.

The wider question of how much of the whole machine to entrust to one supplier is treated as a cost layer structure in our guide to ordering a special purpose machine. Think of the five layers here as a further division of the control and electrical layer described there.

Whether the reason for a stoppage survives is decided in the software design

The most common request heard once a machine is in production is some version of “we want to raise uptime, but we cannot tell what is stopping it”. This is almost never an instrumentation problem. It is a machine software design problem.

PackML defines machine state in a shared vocabulary

One body of thinking, developed in the packaging machinery field, is PackML. Created by OMAC and documented as ISA-TR88.00.02, a technical report of the international measurement and control body ISA, it is a framework that gives machine states a shared set of names.

There are 17 defined states. They divide into states in which the machine rests, such as stopped or idle, and states through which the machine is transitioning, such as starting or stopping. Alongside them, 4 operating modes are defined, covering production, maintenance, manual, and change over. After being organised as version 3.0, the technical report was updated in 2015 and again in 2022.

OMAC sets out the benefits of the framework as shorter development time and independence from any one control platform on the machine builder side, and shorter commissioning, reusable training, and reduced time to recover on the side of the operator using the machine.

Without defined states, the reason for a stop has to be invented afterwards

Whether to adopt PackML as it stands depends on the type of machine. Outside packaging, that level of state transition detail is not always required. What matters is not whether the standard is adopted but whether the machine software itself holds the state the machine is currently in.

A machine with no state is, seen from outside, a binary. It is either running or not running. Try to derive uptime from that machine and the reasons for the not running time have to be written in afterwards by a person. Those written-in reasons then depend on that person’s memory and judgement.

Where states are defined, by contrast, change over, abnormal stop, and waiting for material are recorded as separate things from the very beginning. The two records both say the machine stopped, but only one of them can carry an investment decision.

It changes how the quotation is written

Putting state definition into the specification changes the wording of the quotation. Instead of a vague single line for uptime monitoring, it becomes something like defining the states of the machine and making the state transitions and their timestamps available from layer 5.

This is an item that costs additional money. But attempting the same thing after the machine is in production means going back into the layer 1 program. Editing the sequence of a machine that is running is an order of magnitude more expensive than doing the same work during original design.

Seven items to name as deliverables when you place the order

Once the layers are split, the next step is to write down what you receive from each of them. Leave this blank and you end up with a machine that runs perfectly while your own organisation cannot touch any part of it.

Of these, the two that matter most at an overseas site are the language of comments and the licence for the development environment. Receiving the source is of little use if the licence for the development software exists only at the machine builder. Put the other way round, writing just those two into the order conditions changes the range of future modification options dramatically.

What the EU Machinery Regulation of January 2027 asks of machine software

There is a regulatory change that looks unrelated to a plant in Thailand and yet works its way into machine procurement. It is the European machinery regulation.

Software and safety are handled inside the same frame

Machinery Regulation (EU) 2023/1230 applies from 20 January 2027. On the same date the existing Machinery Directive 2006/42/EC is repealed, with no overlapping transition period.

What distinguishes the regulation is that it pulls software and cybersecurity into the requirements for machine safety. Safety related control systems and software are required to withstand not only accidental failure but deliberate attack. Network connectivity and remote access functions must not create hazardous conditions, and those protections have to be maintained across the lifetime of the machine. Records of intervention must be kept so that attempts at tampering can be traced.

Replacing control software can amount to a substantial modification

The second point that matters to the operator of a machine is the treatment of substantial modification. Where a machine already placed on the market is modified, by adding automation or by updating control software, and that modification creates a new hazard or raises an existing risk to the point where new protective measures are needed, the party that carried out the modification takes on the position of manufacturer of the whole machine. In that case the risk assessment has to be redone and the declaration of conformity reissued.

This is not somebody else’s problem in a Thai plant. Where a European built machine is in use and a decision is taken locally to replace its control software, the line between maintenance and modification becomes a question asked from both the contractual and the standards side.

Standards that examine the development process itself are coming into use

One standard used to evaluate how the software on a machine is built is IEC 62443-4-1, part of the security standards for industrial automation and control systems. It requires defining security requirements, secure design, verification, vulnerability management, and update management as disciplines of the development process. It applies to the party supplying machines and controllers, and the degree of achievement is expressed as a maturity level. In practice, a manufacturer supplying HMIs and controllers has published its certification to maturity level 2 of IEC 62443-4-1.

Related to this, the European Cyber Resilience Act applies reporting obligations for actively exploited vulnerabilities and severe incidents from 11 September 2026, in a framework of an early warning within 24 hours and a detailed report within 72 hours. The bulk of the obligations apply from December 2027.

As the buyer of machine software, you do not need to understand all of these standards. What you do need is this. When you ask a machine builder how they handle security, can they answer in terms of their development process rather than product features?

How much upper level integration to build into the machine software

Decide the layer 5 design machine by machine and it comes out inconsistent across the plant. This layer needs a view of how the whole factory is to be aligned.

Where the standard for connecting machines currently stands

For communication between machines and the systems above them, OPC UA has become the de facto common language. In recent years work has progressed on OPC UA FX, which extends it into real time communication between machines.

As of March 2026 the OPC Foundation has published release candidate V1.00.04, adding Part 81, which covers connected devices and information models, and Part 84, which covers conformance profiles. From 16 to 19 February 2026 an interoperability event bringing together major automation vendors was held in Berlin.

The practical meaning is that a path is taking shape for connecting machine to machine, or machine to controller, across manufacturers by a standard method. At present, however, it remains at release candidate stage, and this is not the moment to write it into the specification of a machine you are ordering now as a mandatory requirement. If something goes into the specification, requiring OPC UA for upper level communication is the realistic line.

Do not let “not needed this time” turn into “never”

Judged on cost alone, the decision on whether to cut layer 5 leans towards cutting. But there are two ways to cut it.

One is not to build the transmission function to the upper system at all. The other is to leave the transmission unbuilt while keeping the data in a state where it can be extracted. The first means going back into layer 1 when you add it later, while the second is completed inside layer 5 alone. That difference bites hard once the machine is in production.

Concretely, this means holding production count, pass or fail, state, and timestamp somewhere inside the machine in an organised form. Even with no destination decided, holding them is something you can do now.

Where to draw the line between in-house and outsourced

The greatest practical benefit of splitting into five layers is that the line between in-house and outsourced work can be drawn at the granularity of a layer.

What stays in house is the specification and the acceptance criteria

Few plants can write every layer themselves. The realistic split is rather to send the writing work out and keep the deciding work in.

For layer 1, the movement order and the thinking behind the interlocks. For layer 2, the conditions under which takt is measured. For layer 3, the criteria for pass and fail. For layer 4, the information to be displayed and the classification of alarms. For layer 5, the definition of the data items. Not one of these can be decided by anybody other than the buyer. Conversely, writing the ladder, tuning the servos, implementing the image processing, drawing the screens, and implementing the communications can all be left to a specialist.

Decide the range that can be touched locally

At an overseas site one more axis appears. Whether the Japanese head office or the local site does the touching.

The realistic landing point is to make layers 4 and 5 locally editable while keeping layers 1 to 3 with the Japanese side or the machine builder under an agreed change procedure. Layers 4 and 5 need continuous change as operations evolve, while carrying a lower degree of direct connection to machine safety and product quality than layers 1 to 3.

That does not mean local engineers can afford not to read layer 1. Isolating a fault requires the ability to read it. Creating a state in which people can read but do not modify is exactly where the language of comments and the upkeep of documentation earn their place. For who handles which part of the work from installation through to volume production, our article on support for equipment commissioning is also worth reading.

Points specific to ordering machine software development in Thailand

Everything so far applies to machine software generally. Assume a site in Thailand and several further conditions appear.

The condition that the machine builder exists only in Japan

Where a machine is designed and built in Japan and then brought to Thailand, the person who wrote the machine software is not in Thailand. Commissioning can be covered by a business trip, but subsequent modification and fault response are exposed to distance and time difference.

What works under this condition is the layer split. Rather than making everything dependent on the Japanese side, decide in advance which layers can be handled locally. Whether screen changes in layer 4 and additions to data items in layer 5 can be done locally in particular changes the day to day operational load.

Separately, bringing a Japanese machine into Thailand raises questions about power supply assumptions and documentation that break down on arrival. Since those are not specific to machine software, see the relevant part of our article on outsourcing PLC program development.

Whether BOI measures for 2026 can be built into the software investment plan

The Thailand Board of Investment has prepared measures for 2026 aimed at productivity improvement by existing operators. Upgrades to machinery and equipment, including automation and robotics deployment, receive relief from import duty on machinery together with corporate income tax exemption for 3 years.

The exemption is capped in principle at 50% of the qualifying investment. Where 30% or more of the qualifying automation and robotics machinery is linked to Thai manufactured content, the cap rises to 100%. Qualifying investment starts at a minimum of 1 million baht excluding land and working capital, and implementation must be completed within 3 years of the issuance of the promotion certificate.

Whether machine software cost falls within scope depends on how the application unit is constructed. Applying for the machine as a complete investment, or carving the software out separately, gives different treatment, and the carved out case needs to be confirmed project by project. At the very least, keeping software cost in its own line when the machine investment plan is drawn up makes it easier to explain at application time.

Write local language training into the specification

A discussion about machine software ends up, in the end, back at people. Putting the layer 4 screens into Thai achieves nothing if what to do when an alarm appears has not been communicated.

What belongs in the specification is a separation between operator training and maintenance training, and an explicit statement of the language in which training is delivered. A machine builder’s standard handover can amount to a manual in Japanese or English and a few hours of operating explanation. Whether that is sufficient depends on the maintenance structure at the local site.

Pre-order checklist

Here are the items you can fill in internally before asking for a machine software quotation.

• Have you split the software the machine needs into 5 layers and written down which layers apply?
• Have you fixed the conditions for measuring takt time, down to workpiece, quantity and starting state?
• If image judgement is in scope, can you physically supply limit samples for acceptable and unacceptable?
• Have you decided how the machine should behave when a judgement is wrong?
• Can you write the information to be displayed and the classification of alarms in your own words?
• Can you list the data items you want out of the machine even with no destination decided?
• Have you written source, comment language, parameters, test specification, change history, licences and remote maintenance into the order conditions as 7 named items?
• Have you decided which layers will be locally editable and which stay with the Japanese side?
• Have you decided who receives training and in which language?
• If you intend to use the BOI measures, have you settled where software cost sits in the investment plan?

Get the first four of those settled and conversations with a machine builder move quickly to a concrete discussion of effort. Go out for competing quotations with them still blank and all you collect is a set of quotations covering different scopes.

Frequently asked questions

What is the going rate for machine software development?

There is no single figure to give. Even for what is described as the software for one machine, a machine with sequence control alone and a machine carrying synchronised multi-axis control, image judgement and upper level integration need different skills and different effort. If you want a sense of the rate, the practical route is to decide which of the 5 layers in this article your machine actually needs, and then ask for a quotation broken down by layer. A layered quotation also makes comparison across suppliers possible.

How does machine software development differ from PLC program development?

PLC program development usually refers to the part of machine software corresponding to layer 1, the sequence control. Machine software development is used in the wider sense that adds motion control, image judgement, operator screens and upper level integration on top. Because a mismatch in vocabulary at ordering time produces a mismatch in scope, it is worth stating explicitly at the request for quotation which layers you mean.

Do we always receive the source code for a machine?

Not automatically. If it is not written into the order conditions, executables alone may be all that is delivered. The thing to check alongside it is the licence for the development environment, because receiving the source achieves nothing if the development software is not at hand. Handover of source and licensing need to appear as two separate items in the contract.

Can PackML be used on machines other than packaging equipment?

The thinking transfers. PackML is a framework that defines machine state through 17 states and 4 operating modes, documented as ISA-TR88.00.02. Applied wholesale to machines outside packaging it can be excessive, but the design philosophy, that the machine software itself holds the state the machine is currently in, is what decides whether uptime can be measured later. Even without full adoption, putting just the classification of states into the specification is worth doing.

Can machine software development be entrusted to a company in Thailand?

It depends on the layer. Screen changes in layer 4 and data extraction in layer 5 are areas where a local capability is comparatively easy to build. Rewriting layer 1 sequence control wholesale, on the other hand, is work that presumes the original program comes with tidy documentation and comments. If local handling is the intention, writing the language of comments and the licence for the development environment into the conditions at the time the machine is ordered is the substantive preparation.

Does the European machinery regulation affect plants in Thailand?

It applies directly to machines placed on the European market, but indirectly it does matter. Where a European built machine is in use, the question arises of whether a control software update or an addition of automation counts as a substantial modification. Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and pulls software and cybersecurity into the requirements for machine safety. It is worth settling, inside your maintenance contract and your agreements on modification with the machine builder, where maintenance ends and modification begins.

Summary

Here are the main points.

Machine software development quotations cannot be compared because of scope, not because of price. The software on a machine is a set of five layers with different characters, namely sequence control, motion control, vision and measurement, HMI and operator screens, and upper level integration, and the measuring stick for acceptance differs by layer. A one line quotation flattens all five of those measuring sticks into one.

Where quotations differ between suppliers, the difference sits at the joints between layers rather than inside them. Who decides the path, who owns the definition of a defect, who decides what appears on the screen, and where the granularity of the data is decided. Fill those four in before you go out for quotations and the spread between quotations becomes readable as a difference in capability rather than a difference in scope.

Whether the reason a machine stopped can be traced afterwards is decided by whether the machine software holds its own state. PackML is a framework defining machine state through 17 states and 4 operating modes, and even without adopting it wholesale, the idea of classifying states transfers.

On the regulatory side, Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and builds software and cybersecurity into the requirements for machine safety. That replacing control software can amount to a substantial modification, and that the development processes of machine builders are beginning to be evaluated against standards such as IEC 62443-4-1, are both material to the party selecting a machine. In Thailand, BOI measures for 2026 provide corporate income tax exemption for upgrades to machinery and equipment, which makes it worth settling how software cost is positioned at the investment planning stage.

Finally, the line between in-house and outsourced work can be drawn at the granularity of a layer. Send the writing work out and keep the deciding work in. Manage that split and machine software does not become a black box.

At the stage where the scope of the machine software is being decided, the specification of the machine itself is usually not yet settled either, which is entirely normal. TOMAS TECH works from exactly that point, helping Japanese manufacturers operating in Thailand think through which layers realistically belong in the order specification and which are better kept in house. You are welcome to get in touch while you are still weighing options and before any supplier has been chosen, through our contact page.

References

• OMAC – PackML
• Frostbyte Pro – PackML States Explained
• IoT Analytics – AI in machine building 2026
• European Standards – EU Machinery Regulation 2023/1230 Compliance Guide
• Nemko – EU Machinery Regulation 2023/1230 Cybersecurity Obligations
• Association for Advancing Automation – Expert Insights on the Machinery Regulation
• EXOR International – Industrial Cybersecurity in 2026
• OPC Foundation – Field Level Communications Corner March 2026
• B and R Industrial Automation – OPC UA FX
• Mahanakorn Partners – Thailand’s BOI in 2026