The control layer for the conveyor, written by the people who built the conveyor. Sortation supervision, product flow, exception handling and an operator interface that explains itself, taken module by module rather than bought as a suite.
Ask five vendors where a WCS ends and a WES begins and you will get five different answers, each one shaped by what that vendor already sells. A WMS company extending downward calls its scheduler a WES. A conveyor company extending upward calls its supervisor a WES. The category exists partly because it is easier to sell a three-letter acronym than to say precisely which decisions a piece of software makes.
Meanwhile your facility needs three things: orders released, cartons routed, equipment running. Everything else is packaging.
Stated as plainly as we know how, and we have no incentive to blur it because we do not sell a control-system license:
Most facilities being sold a warehouse execution system need a sortation supervisor, honest exception handling and an interface that explains a fault. That is a considerably smaller purchase than the category name suggests, and pretending otherwise is how buildings end up with three overlapping platforms and a layer of custom glue code that no one is willing to own.
The fragmentation is not an accident of the software market. It is the same fragmentation that breaks conveyor projects: one company sells the steel, another writes the controls, a third supplies the execution software, and when the line will not hold rate every conversation becomes a jurisdiction problem. The integration seam is where the throughput goes.
OIP closes the seam that matters most, because we are already on both sides of it. We design the layout and the zones. We fabricate the steel. We write the PLC and HMI code that makes the line hold rate. Extending that upward into the layer that decides where product goes is a short distance, and it means the software was not written against a specification of your conveyor. It was written by the people who commissioned it.
What that gets you in practice:
Modules, not a suite. Take the ones that solve a problem you actually have.
Every building is different, which is a useless thing to say on its own. Here is what different actually looks like.
Sortation Supervisor and HMai. Nothing else. You keep your WMS, you keep your conveyor, and you get a layer that assigns lanes, proves the divert happened, and gives operators an interface that explains a fault instead of printing a code at them.
Add the visibility layer. Exceptions become a queue somebody can work rather than a pile of no-reads nobody reconciles, faults get a history, and the throughput conversation stops being an argument about whose number is right.
The whole stack, alongside conveyor we designed, fabricated, programmed and commissioned. One scope, one interface, one support call, and no integration seam between the equipment and the software because the same team built both.
Where OIP actually stands. It is in active development, and we would rather tell you that than let you find out. The architecture is built and runs end to end as a working application across every module listed above. HMai and the field assist tool, which lets a technician photograph a fault and get the zone context and likely cause back, are working prototypes. The data behind the demonstration is simulated, because the alternative would be showing you somebody else's operation. What Sunshine State Automation sells today is the conveyor system, the controls and the commissioning. OIP is the layer we are building on top of that work, and the customers who come in early are the ones who get to shape it.
In honest terms: a warehouse control system talks to equipment, and a warehouse execution system decides what work should happen next. The trouble is that the boundary moves depending on who is selling. A WMS vendor extending downward calls its scheduler a WES; a conveyor vendor extending upward calls its supervisor a WES. Both are describing real functions, but the line between them is drawn by sales territory rather than by engineering. We have no reason to blur it, because we do not sell a warehouse control system license: what a facility actually needs is orders released, cartons routed and equipment running, and the label on the box that does it is the least interesting part.
Often, no. A large share of facilities being sold a warehouse execution system need a sortation supervisor, honest exception handling and an operator interface that explains faults. That is a much smaller purchase than the category name implies. The question worth asking is which decisions your WMS is genuinely making and which ones are quietly being made by a spreadsheet, a supervisor or a piece of glue code nobody owns.
No, and we would rather say so plainly. OIP is in active development. The architecture is built and demonstrated end to end as a working application, and the operator-facing pieces, HMai and the field assist tool, are working prototypes. The data behind the demonstration is simulated, because the alternative would be showing you another customer's operation. What we sell today is the conveyor system and the controls; OIP is the layer we are building on top of that work, and early customers shape it.
That is the point of the design. The modules are a menu, not a suite. Plenty of customers need sortation supervision and an operator interface and nothing else, and that is a legitimate scope rather than a downgrade. Others take the stack end to end alongside a new system. What you do not do is buy layers you have no use for so that the parts you need will function.
Yes, and that is the normal case. OIP is a control and execution layer, not a replacement for your system of record. Connected Systems exists to speak to whatever is already in the building: PLCs, scanners, hosts, goods-to-person, packout, SQL, APIs, MQTT, OPC UA and file drops.
The premise is backwards. Sunshine State Automation is as much a software company as a hardware company, and on most days more of one. The steel is how product moves. The code is what decides whether it moves at the rate you bought it for, and it is where nearly every underperforming system we are called into went wrong. Building both is the only way to hand a customer one seamless system instead of a set of parts that technically interoperate. The second reason is transparency, which this industry is badly short of. Most buyers cannot get a straight answer about which parts of a system a vendor actually builds, what the software genuinely does, or what it will cost to change something in two years. We would rather put the whole package in front of you, name every step we perform and every step we buy, and let you judge it on that.
We will walk you through the platform and tell you honestly which parts of it exist today and which parts you would be helping us build.