In today’s modern manufacturing landscape, data flows across an increasingly diverse technology stack, including systems like ERP, SCADA, IIoT devices, cloud analytics, AI platforms, MES, and more. Each captures a different view of what’s happening throughout production. Though without a shared understanding of state, systems and processes can become out of sync.
State is the foundation of execution, compliance, traceability, and analytics. Yet, many times, state is managed inconsistently or redundantly across systems, creating conflicting definitions and understanding of production.
This piece delves into why state matters, why centralized state management should be a core capability of your MES, and how TrakSYS implements state machines to enforce event-driven automations across the enterprise.
Managing State: The Overview
This video provides a quick introduction to managing state in manufacturing environments: what states look like in workflows, how state machines define allowable transitions between states, as well as what this all looks like in TrakSYS.
Okay. Well, welcome back to another TrakSYS technical short. I am Ryan McMartin. I'm the director of product marketing at Parsec Automation. And today we are gonna discuss a TrakSYS feature called state machines. And a very I guess typically overlooked feature of TrakSYS MES but it's very important. So let's kind of get into it and I can set the stage and explain what's going on here. So let's make this full screen. Okay. So TrakSYS state machines. Alright. So no doubt if you are involved in any sort of implementation of a technical product like an MES system, like TrakSYS, you are gonna have to manage state. Okay? Now there's different there's different pieces of managing state. There's like a kind of the the you know, scripting coding state that we talk about with web pages and that sort of thing. What I'm talking about though is the life cycle stage or state of a product, of a task, of an inventory item, going through stages of receiving and what have you. So on the screen here, I've got an example state. Right? Here's a example, let's say, a order, a job, production order, going from ready and then to running and then complete. Okay? And so in here, I'll use my mouse, but we have a ready state, we have a running state, we have a complete state. And then in between each state is a transition, right? We transition from ready to running when we start the order. We transition from running to complete when we complete the order. Then when we need to reset, right, we do that reset. We go from complete back to ready for the next order. Pretty simple, makes sense. But states can get very, I don't know, they can kind of compound on each other and get complex, right? So for example, we had an on hold step, right? The order is running and we put it on hold and then we might want to resume that. There's a couple transitions there. Well, what if we're on hold and we abort that run? Or we're running and we abort that run. Right? Or we need to reset from that aborted run. So very quickly, there's going to be some work that needs to be done to manage the different states and the different transitions between states that a product takes. Now typically, this all happens in script. Okay? So you're creating a program, you are designing a page where someone clicks a button, you have a script that's running in the background that's doing some things on a cadence. You have third party applications interacting with your MES that might update state. You're updating states or managing transitions in all these desperate, disparate areas. So wouldn't it be nice if you could manage the state? You could still control the state in all those areas, but manage what happens when you change the state in one central area. And that's really what we're talking about when we talk about TrakSYS state machines. So we'll get into this a little bit. So what are TrakSYS state machines? Well, they're configuration driven. So you're defining states in the product, you're defining those allowed transitions between states. We've got API calls that help you validate which transitions are allowed. And then we allow you to basically define actions on a transition. So if a transition happens, if you change state, what is going to occur, right? And what is allowed to occur when that change happens? So this really prevents just cleaner governance and consistent behavior across everywhere you are changing state or changing state even in different sites. All right. How do we, as an end user, what do you do? How does TrakSYS work? Or how do you pick up on what state is a current object is that? Well, we we supply every data table in in the system. So think four hundred data tables. Right? There's a field on every table called user state. So when you set up a state machine and you apply it to an entity like a job, a batch, an item, or a task, it's writing to this field. Now of course, could manually write to this field and nothing's stopping you from creating your own scripts and managing your state manually, but this field is really intended to be managed by the state machine feature inside of TraxSYS. So typically, well, actually what happens is when you create a state machine, here's a little image of it and I'll show you inside of TrakSYS in a second what this looks like. But, I've set up job state. I set different states ready, running, complete, on hold, aborted. And what TrakSYS is doing in the background is it's creating these global enums. Alright? And then you can basically reference these enums. Now imagine, if you didn't have this, you'd be creating enums or reference lookups all over the place in your MES system. So this makes it really central and nice to just do it in one place, manage it in one place, access the enums all over the system. Okay, what does that look like? Kinda looks like this. So here's a little snippet of some script that we write inside of TrakSYS. So if you're not familiar TrakSYS is a platform to managing execution on the shop floor and really all over your manufacturing operations, all throughout your manufacturing operations. Here's an example though where you can extend the functionality of TrakSYS and do some custom scripting in the product. So inside of TrakSYS we can say, let's say when a page loads up, we might want to access or set a state on a particular job. So in this case you're seeing that we're accessing some methods inside inside of TrakSYS and you'll see that those those enums are kind of ported through to show in IntelliSense in the scripting inside of TrakSYS, you can pick up on those on those enums and those newly created states and really easy. I don't have to guess. I don't have to say, well, what is what is one equal again? What is what is zero equal again? What is two equal again? I just can say, oh, okay. I wanna set this job to aborted or to running or to ready or to on hold. Alright, very simple. Something that I will remember to show you when we look at TrakSYS is that once you have these state machines set up, you can quickly access the values in that state machine by using an enum list part. So when you're generating or creating your TrakSYS pages, if you want to kind of push that those those options to a page, can do that by the enum list and you'll see here you can create nice little drop downs to select states so that your users can change states. And you can even validate, right, to say, what is what is the right transition from the current state I'm at? And speaking of validation, right? So we mentioned you might be able or you might have to change state on certain pages inside of your MES, like inside of in different parts of your MES solution. Maybe there's the long running scripts that are periodic scripts that are running in the background. Maybe a third party application is sending a state update or maybe you have to sync the states in a third party application with your MES. And then of course TrakSYS has some workflow capabilities which I'll show in a second. But you might be changing state or looking at state or trying to validate state in all of these different areas. Typically, again, you'd have to script and write calls out to say, Hey, look, what is my current job state? And all that. Now we make it very easy with state machines. So the key here is that you have a centralized state, centralized logic change area for state. All right, what does that look like? Well, you're still writing a little bit of script here, but it's all kind of tucked into the state machine feature. And so there's some APIs inside of TrakSYS that let you essentially access these methods. So one of the methods is, is transition possible? So you're saying, hey, look, my job is currently at this job state of ready. I wanna switch it to running or the user wants to switch it to running. Is that allowed? Okay. It'll bring back true false. And then of course, if it's true, you can do the next thing. Great. Execute that transition, right? Execute that running transition state. And then TrakSYS now has the capability of essentially performing that state change and running any downstream activities associated with that. And then the last thing I'll show you here is that this is very tightly integrated with the TrakSYS workflow feature. And so there's some steps, some workflow step types that you can drag on the workflow chart. Wait for a state change, wait for a state, wait for a state change, and then set a state value all in the in the kind of workflow configuration. So it makes it pretty easy to set up. Alright. So with that, let me, jump over to the product here and show you what I'm talking about. So let's try this. Okay. So sometimes, yeah, it's just a little easier to see this when we are looking at the product. So I'll kinda walk you through where this stuff is all configured. So I'm in TrakSYS. I'm in a development I'm in the developer area of TrakSYS. Under my workflow, I'll go to state machines and you can group your different state state machines or states. So I have a state machine called job state, and it's pretty easy to configure here. I've got states and transitions, so I'll click under states. I've got my five states ready, running, complete, on hold, or ported. I can just show you how this is set up. If I double click on one of these states, it's really easy. I give it a name, I give it a key, and I give it a value. Okay? Cannot get any simpler than that. When we come back to the transitions, the allowable transitions mind you, right? I'll click in here. I I created a start transition. Double click on it and just to show you that you basically set the name of the transition, you say from what state machine to which state machine, so from ready to running and that creates that allowable transition. Now you'll notice on each kind of area here, so on the job state level, on that state machine level, I can write some scripts to get the state of to get a job state, so I can write that script in here. I can write some logic to change a state. Okay? Pretty easy. And then on the transition, I can when someone wants to execute a transition, I can do some prerequisite scripts there before the transition is executed and then I can run some execution scripts and some kind of actions downstream from that. So pretty easy to set up a state machine, set up the transitions, and then determine what happens when a transition occurs. I think that's pretty neat. And then if we come back to workflow, just to give you a sense of what this looks like, I'll come into a demo workflow I created, state machine demo. Let's go into the diagram. And here's the diagram. If you're not familiar with that workflow tool, it's a nice way to manage process and, you know, we call them process definitions, but basically process templates in in your manufacturing environment. So you see here we have state machine. Pretty easy. You just drag these out, you know, draw lines to connect stuff. I'll delete that one. But essentially, this little workflow is when it starts, it's going to set some job value or set some system state value. It's going to wait for a running state to change, it's going to wait for that change. And then depending on the outcome of the change, we can start downstream processes, right? So if something gets turned to hold, then we start the hold process. If something gets completed, we start the complete process. If something gets aborted, we start the job abort process. And then those are separate workflows that can be managed separately than this. So I think you get the idea that in summary here, TrakSYS state machines is one of those things that when you're typically buying software you're not thinking about, hey, how am I going to manage state? Mostly are thinking about when you're buying MES, hey, how's it gonna help me with quality? How am I gonna measure my performance and my efficiency? And all the typical operations level stuff. But when it comes to implementing a product like this, it's complex. And this is just one of those ways that Parsec with TrakSYS makes it makes it, you know, as as our slogan says, as simple as possible to manage state across your sites in your enterprise in MES. So with that, I'll wrap it up. Of course, if you are at all interested in learning more about TrakSYS, know, follow us on our website. There's a lot of learning material on there. Reach out parsec corp dot com if you wanna learn more. So, with that, thanks a lot. We'll see you next time.
Interested in learning even more about the intricacies of state management and how to govern it within your MES? Keep reading.
What is “State” in Manufacturing
In the context of manufacturing, “state” is the current condition or status of a business object (item, entity, batch, task, etc.) at a moment in time. It answers questions like:
- Is this order running or on hold?
- Is this tank idle or in CIP?
- Is this batch approved, rejected, or quarantined?
- Is this workflow step pending or complete?
Each entity across production has a series of states to describe its status. Here are some common examples:
|
Entity
|
States
|
|
Production Orders
|
Planned → Released → Running → Complete → Closed
|
|
Equipment
|
Idle → Running → Setup → Down → Maintenance
|
|
Materials & Lots
|
Received → Quarantined → Released → Consumed → Scrapped
|
|
Tasks & Approvals
|
Pending → Assigned → In Review → Approved → Rejected
|
A state may just seem like a label, but it drives business rules, system behaviors, physical actions on the plant floor, and communication between systems. Thus, without consistent state definitions, systems won’t agree and can lead to incorrect scheduling, inaccurate OEE, failed audits, misinformed decision-making, and more.
The Common Problem: State Drift
Without a clear state management strategy or system in place, each system can define state independently, for example:
- ERP determines the financial lifecycle of orders
- MES defines the execution lifecycle
- SCADA specifies machine tag values
- LIMS manages quality disposition
- CMMS tracks the maintenance lifecycle
When each of these systems has its own models, there is no centralized source of truth for state and transition definitions. This can cause “state drift,” where systems disagree about the reality of an object’s state.
State drift can result in a range of miscommunications, including:
|
Issue
|
Example
|
Impact
|
|
Conflicting statuses
|
ERP says Closed, MES says Running
|
Bad costing and incorrect KPIs
|
|
Inconsistent machine states
|
Each line codes downtime differently
|
Inaccurate or lack of root-cause analytics
|
|
Redundant scripting
|
Each system redefines logic
|
More time spent on script maintenance
|
|
Manual mapping between apps
|
Integration per interface
|
Slow deployment
|
The Solution: Centralized State Management in MES
The solution to state drift is a centralized state management system. A unified understanding of state ensures that all systems reference a standardized source of truth with consistent definitions, rules, and transitions. This can be achieved with an MES—with tools like TrakSYS State Machines.
MES is the right place to own and manage state because it acts as an execution layer for your technology stack. It’s close enough to machinery to capture real-time transitions, yet also aligned with business systems, which enables a holistic, enterprise view. This positioning, plus its knowledge of operational context (order, material, equipment, personnel, quality, etc.), allows your MES to track and act on state.
For example, when an order moves to Running, TrakSYS can release materials, update OEE, start data collection, trigger compliance workflows, and notify external systems. Or, when equipment moves to Down, TrakSYS can classify root cause and initiate maintenance workflows.
Using TrakSYS to unify and manage states can result in:
- Standardized deployments by offering standard, preconfigured models that can be reused across sites
- Better operational discipline with readily available, software-enforced SOPs
- Reduced validation efforts due to less custom code to review
- Improved KPI accuracy by eliminating conflicting running and downtime states
- Stronger compliance and regulatory readiness with detailed logs of transitions and approvals
Conclusion
State management may not be the first thing that comes to mind when contemplating how to streamline your operations. However, it’s undeniable that state is a core pillar of digital manufacturing.
When fragmented across systems, misaligned states erode data integrity, compliance, and process control. When centralized—particularly within an MES—proper state management becomes the engine that drives consistent execution, automated workflows, accurate analytics, and enterprise-wide standardization.
TrakSYS State Machine can deliver centralization capabilities in a configuration-driven, integrated, and auditable way that fits seamlessly into modern manufacturing operations. Interested in learning more about how our MES can help you manage state? Contact us today.