Engineering the business case for intelligent transport systems

How software-driven architecture is redefining the relationship between mechanical and controls engineers

Key Highlights

  • Controls engineers must collaborate with mechanical engineers during concept development to establish shared definitions for station/route IDs, carrier state models, sensors, actuators, expected cycle times and fault-recovery rules rather than taking on a fixed mechanical layout late in the process.
  • To prevent network traffic and processing bottlenecks, system integrators should architect a multi-tiered infrastructure where local PLCs independently manage time-critical motion, safety and routing decisions, while edge IPCs asynchronously handle high-volume analytics, data filtering and enterprise communications.
  • Effective troubleshooting and HMI design require tracing a carrier’s digital and physical state sequentially across network, logic and fieldbus layers to pinpoint root causes, using live system flow maps rather than relying on localized hardware replacement or basic alarm lists.

Khyati Desai is FlexLink’s product manager, hygienic solutions.

When a machine builder transitions to independent, software-driven transport systems, how does that change the fundamental design relationship between the mechanical engineer and the controls programmer?

Khyati Desai, product manager, hygienic solutions, FlexLink: Although puck and pallet conveyors are mechanically different from linear-motor independent-mover systems, the same design shift appears as soon as routing, carrier identification and process recipes become software-configurable. Mechanical and controls engineering can no longer work as two sequential disciplines, with the mechanical layout completed first and the controls programmer asked to make it run afterward. They must co-design the transport concept from the beginning.

The mechanical engineer still owns fundamentals, such as carrier stability, product support, acceleration limits, transfer geometry, accumulation pressure, access and safe maintenance zones. The controls engineer defines the carrier state model, routing decisions, recipe logic, queue management, interlocks and fault-recovery behavior. The most important shared deliverable is an interface contract: station and route identifiers, sensor and actuator definitions, carrier data, expected cycle times, fault states and recovery rules.

This collaboration should start during concept development, supported by simulation or at least a digital flow model. Early co-design prevents a mechanically elegant layout from becoming difficult to control, and it prevents sophisticated software from depending on unrealistic physical behavior.

As industrial motion relies increasingly on software layers, tracking algorithms and centralized data, what new skills do standard field maintenance technicians need to troubleshoot these systems?

Khyati Desai, product manager, hygienic solutions, FlexLink: Maintenance technicians need to add software and data literacy to their traditional mechanical and electrical skills. They do not need to become application developers, but they should be able to diagnose the system layer by layer: product and carrier, mechanical transport, sensing, distributed I/O, network communication, PLC logic, routing data and supervisory software.

Practical skills include reading PLC diagnostics, understanding basic ladder or structured-text logic, checking fieldbus topology, verifying RFID or identification data, interpreting drive and I/O status, using HMI event logs and restoring approved software or parameter backups. Technicians also need to understand version control at an operational level—knowing which PLC program, device firmware and recipe set are approved for the machine.

A useful troubleshooting method is to follow the carrier’s digital and physical journey. Is the puck or pallet mechanically present? Was it detected? Was its identity read correctly? Did the controller assign a valid route? Did the downstream station acknowledge capacity? This approach is more effective than replacing components based only on the location of the stoppage. Role-based access and cybersecurity hygiene are also essential, because maintenance laptops and service accounts now interact directly with production networks.

High-speed intelligent transport and motion systems generate massive amounts of real-time operational data. How should a system integrator architect the edge computing or PLC infrastructure so this traffic does not bottleneck the primary machine control loops?

Khyati Desai, product manager, hygienic solutions, FlexLink: The key principle is to separate deterministic machine control from data-intensive monitoring and analytics. Safety functions, actuator commands, carrier routing decisions and critical interlocks should remain in local controllers or in the cell PLC, where execution is predictable. High-volume historical data, dashboards, condition monitoring and enterprise integration should run in a separate task, processor or edge-computing layer.

A practical architecture has three levels. Device or module controls handle immediate functions. The cell PLC manages routing, sequencing and machine states. An edge IPC or industrial server collects time-stamped events, aggregates data and passes selected information to SCADA, MES or cloud systems asynchronously. Raw tags should not be polled at unnecessary rates; data should be filtered at the source and published as events, state changes or calculated KPIs.

System integrators should also use network segmentation, managed switches, appropriate quality-of-service rules and store-and-forward buffering. Database queries, API calls and report generation should never sit inside the time-critical PLC scan. Infrastructure should be sized for worst-case event bursts, such as restart after a blockage, not only for average traffic. The objective is to preserve control-loop determinism even when the information layer is busy or temporarily unavailable.

With advanced transport systems making manufacturing processes highly dynamic and recipe-driven, how should the HMI evolve to help operators visualize complex routing, bottlenecks and system errors in real time?

Khyati Desai, product manager, hygienic solutions, FlexLink: The HMI should evolve from a collection of device screens and alarm lists into a real-time flow map. Operators need to see where carriers are, what state they are in, which route or recipe they are following and where flow is becoming blocked or starved. A good overview combines the physical layout with live information such as queue length, station status, cycle-time deviation and the number of carriers waiting, processing or recirculating.

The system should present different levels of detail for different roles. An operator needs clear production status and guided recovery. A maintenance technician needs sensor, actuator, network and carrier-identity diagnostics. A process engineer needs trends, route performance and bottleneck analysis.

Get your subscription to Control Design’s daily newsletter.

Alarm design is particularly important. Instead of reporting only that a stop or sensor is active, the HMI should explain the affected location, probable cause, upstream and downstream impact and the safe recovery sequence. Time-line replay and short event histories can help teams understand the chain of events before a stoppage. The HMI should reduce complexity by showing actionable context, not expose every internal tag to every user.

Intelligent, software-configurable motion hardware has a higher upfront component cost than traditional hardware, such as belts, chains and indexing tables. What advice do you have for a machine builder trying to justify that higher bill of materials (BOM) to a procurement-focused customer?

Khyati Desai, product manager, hygienic solutions, FlexLink: Do not justify the investment by comparing one transport component with another. Compare the complete production outcome and lifecycle cost. A higher transport-system BOM may be justified if it reduces custom mechanical engineering, hard tooling, floor space, work-in-process, changeover time, commissioning effort, quality losses or future modification costs. It may also allow multiple product variants to run on the same line through software-configurable routing rather than dedicated mechanical paths.

The strongest business case uses the customer’s own scenarios. Quantify the value of one avoided day of downtime, a shorter product changeover, faster introduction of a new variant, reduced manual handling or improved traceability during a quality investigation. Include the cost of future expansion and reconfiguration, not only the initial installation. Modular, standardized functions and pre-assembled mechatronic modules can also shift work from unpredictable site integration into more controlled engineering and testing.

Procurement may see a component premium, but operations and finance should see the payback. Present a transparent total-cost-of-ownership (TCO) model with conservative assumptions, sensitivity ranges and a clear link between technical capability and measurable business results.

When trying to justify a shift from traditional mechanical conveyance to software-driven transport technologies, what OEE metrics or data points do you use to convince a skeptic?

Khyati Desai, product manager, hygienic solutions, FlexLink: Start with the three OEE elements, but add transport-specific flow metrics. For availability, measure unplanned stops, micro-stop frequency, mean time to repair, restart time and the percentage of faults that operators can recover without specialist support. For performance, measure throughput at the actual product mix, carrier cycle-time variation, blocked and starved time, queue length, buffer utilization, recirculation and changeover duration. For quality, track first-pass yield, misrouting, skipped-process prevention, damage, rework and the speed of product containment when a defect is detected.

Other useful indicators include work in process, labor intervention, energy per transported unit, time required to launch a new recipe and the engineering hours needed for a line modification. The comparison should be made under the same operating conditions and product mix, not against a theoretical maximum-speed figure.

Carrier-level identification is especially valuable because it reveals where time is actually lost. It can distinguish a transport problem from a slow process station, an unavailable downstream resource or an unstable recipe. The most persuasive evidence is not that the system moves faster in isolation, but that it maintains higher sellable throughput and more stable OEE as product variety and production complexity increase.

Tell us about one of your company’s state-of-the-art transport-system products.

Khyati Desai, product manager, hygienic solutions, FlexLink: One of FlexLink’s most advanced transport offerings is its modular puck-and-pallet handling platform. The principle is to place each product on a controlled carrier and then route, buffer, position and track that carrier according to the needs of the process. For small, fragile or difficult-to-convey products, the X45 puck handling system uses compact round pucks to create a stable and repeatable product interface (Figure 1). For assembly, test and production flows, FlexLink offers single-track and twin-track pallet systems for products ranging from lightweight components to much heavier loads.

The carriers can be uniquely identified, for example through RFID-enabled pallets, so products can follow predefined routing paths or recipes. Standard functions such as stops, locating units, merges, diverts, transfers, lifts and rotations make it possible to create layouts for balancing, buffering and precise positioning without designing every function from the ground up.

The state-of-the-art aspect is therefore not speed alone. It is the combination of modular mechanics, configurable routing, product-level identification and scalable control architecture. This gives a machine builder a platform that can support different product variants, process sequences and future line changes while maintaining controlled product flow.

About the Author

Mike Bacidore

Editor in Chief

Mike Bacidore is chief editor of Control Design and has been an integral part of the Endeavor Business Media editorial team since 2007. Previously, he was editorial director at Hughes Communications and a portfolio manager of the human resources and labor law areas at Wolters Kluwer. Bacidore holds a BA from the University of Illinois and an MBA from Lake Forest Graduate School of Management. He is an award-winning columnist, earning multiple regional and national awards from the American Society of Business Publication Editors. He may be reached at [email protected] 

Sign up for our eNewsletters
Get the latest news and updates