LifeInVistaprint

October 9th, 2015

Manufacturing Workflows with Blockly and Microservices

Author: Chris Higley

Suppose you are an engineer in a manufacturing plant, trying to figure out how to cope with a defect arising in a particular type of product, say, coffee mugs. The defective mugs need to be set aside and checked after they’re made . Ideally, an operator would only have to scan a mug electronically and have the screen tell him to set the product aside or to continue. But no such logic is present in the plant’s software. A change is needed.

In a traditional software development process, implementing such a change would require the plant engineer to submit a software change ticket, clarifying his ideas with software engineers, and waiting weeks for a new release that contains the feature. That’s a slow, wasteful process.

Manufacturing at Cimpress thrives off of change. Small, impactful improvements which are made every day in our plants provide a continuous evolution towards efficiency. A core component of this philosophy is that the people closest to the process are in the best position to improve it. Plant floor operators are constantly encouraged to come up with ways to improve their own process, as in our mug scenario, and indeed many valuable suggestions come from them. While traditional methods of process improvement are effective, they leave a gap that may prevent plant engineers from continuing to push the boundary of efficiency. That gap is software.

What if our mug-related software change took minutes instead of weeks? As part of my summer internship at Cimpress, I created a tool that lets plant engineers make certain kinds of changes to the software themselves, without needing a traditional programming language. You see, certain kinds of changes don’t require major software overhaul, just the translation of simple logical concepts into new processes. Through the tool, plant engineers are empowered to easily craft these processes, called “workflows,” and put them to use on the plant floor.

Workflows

Our plant engineers create and configure workflows through a simple web interface. They construct the logic of a workflow via visual programming, which represents programming language constructs as graphical elements that may be more easily understood by those with little coding experience. The tool uses Google’s Blockly library, which presents the user with draggable blocks that fit together to create a program. Here’s a sample workflow created with the software.

The blocks available to an engineer include traditional programming components (if statements, variable assignment, etc.) and manufacturing-specific concepts like “get item” and “print shipping label.” The green blocks allow a workflow to interact with a user. “Scanned text” represents any text input from a station on the plant floor (known as a “floor station”), and “Return” displays text to an operator. Together, these blocks define a workflow which can then be assigned to particular floor stations.

Workflows are used at floor stations through a web browser. At startup, the system will either determine which workflow should execute at a station based on a backend configuration, or prompt the user for a workflow ID if no such configuration exists. The image below is of a simple scan-response page.

higley-scan-cropped

The tool does not directly query databases or communicate with hardware to execute workflow logic; it depends on external services for those operations. Software engineers who wish to expose services to the tool need only register the details of their API, and corresponding blocks will be automatically generated for use in creating a workflow. Because services are dynamically registered with the tool, it can be easily used in a multitude of environments.

A mock setup for an API call is below. In addition to containing basic information about the service, it configures the kinds of inputs that it will take in and how they will be relayed to the API.

higley-api-call-block

Architecture

The software is built from and dependent on microservices: independently deployable, highly interoperable programs. Each microservice typically serves a single purpose and exposes a RESTful API for use by other services. A diagram displaying the tool’s microservices is below.

higley-microservices

Developing and refining this model into something that was logical and practical was the first major challenge of this project. It has ultimately resulted in a solution that is cleaner and more maintainable than a monolithic system. Each microservice can be described as follows.

Core: The core microservice is the heart of the tool. It manages the system’s resources (e.g. workflows, station configurations) in a Git repository and exposes them through its API. It also handles the actual execution of workflows.

UI: The UI microservice entirely deals with floor stations. It serves web pages to operators and communicates with the core to execute workflows.

Configuration UI: The configuration UI sets up the system. It provides a website for creating and modifying workflows, station configurations, and custom blocks. It communicates with the core, which actually “owns” these resources.

A key goal of this tool is modularity. For that reason, it is not tied exclusively to executing Blockly workflows. While today, workflow logic is only stored as the XML output generated by Blockly, the system is designed to be easily extensible for new logic-modeling frameworks that may arise.

As noted above, logic is stored as raw XML. If the XML is marked as being Blockly output, it will be parsed by the Blockly parser. All parsers generate object trees that are understood by the software independent of their origin. Upon workflow execution request (i.e., when a scan is performed), a tree is passed into the executer, which walks the tree and evaluates each node. API calls are all represented by a specific kind of node which makes a network call to an API.

This system is ultimately about providing flexibility and control to the engineers to whom the manufacturing processes are already entrusted. Its usefulness is determined by the ways in which they augment their prior procedures. The tool is also only as useful as the external services to which is has access; it cannot operate in a vacuum, but relies on those services to do “actual work.” Software developers are therefore not cut out of the system, but are an integral part as they enable the system to cooperate with their own services. By automating tedious changes, my tool helps manufacturing software developers to focus on more significant work. The result is more efficient software development and a more agile manufacturing process.

Chris Higley spent the summer of 2015 as a software engineering intern at Cimpress. He is a senior at Rensselaer Polytechnic Institute studying computer science and information technology.

Recent Posts

Join Life in Vistaprint Search Jobs