Systems Engineering at JLS Automation

Most of my earlier work was mechanical design, where I was handed a problem and designed a machine to solve it. As a systems engineer, my job is figuring out what the problem actually is, deciding what shape the answer takes, and making sure our mechanical, electrical, and software teams all build the same machine. That starts with understanding what the customer really needs, which isn’t always what they first ask for.

At the start of a program, I write the scope of work and define the main configuration of the machines: which robots, cameras, tooling, conveyors, and interfaces to the equipment around them. Through design, I review the engineers’ work to keep the disciplines converging. We also simulate the programs and build the initial machine software configuration. Once the machine is built, I’m involved in startup, commissioning, factory acceptance testing, and installation and support at the customer’s plant. I like that the person who decided what the machine should be is the same person who finds out whether it works.

Most of the systems I’ve worked on deviate from our standard software framework, so I add the features they need, like custom inputs, tooling control, sensor behavior, safety reactions, and pick logic, along with camera logic in Cognex and LMI. A lot of that happens during commissioning, when the machine is in front of me and there’s no slack in the schedule. I wouldn’t call myself a software engineer, but being comfortable in that layer has mattered most when a project couldn’t wait.

All of this work is in high-sanitary food production, including raw and cured meat, frozen protein, and snack food, with machines in wet, washed-down spaces. Choosing the right sanitary level early is a systems decision that everything else inherits: nothing should hold water or trap product, everything has to be reachable for cleaning, and materials have to be certifiable.

Programs have ranged from single machines to 16 machines across 8 packaging lines, where the hardest problems were often at the interfaces with other vendors’ equipment rather than inside our own machines.