Automation ideas and explanations as seen in our Boston HQ TEC!

As automations became more sophisticated, adding appropriate and intuitive automations was an important part of updating the Tulip Experience Center (TEC) from version 1.0 to 2.0.

As you know, automations are done in the background, so this post was created to explain what the automations in TEC 2.0 do, which stations they’re used at, and how they fit into the rest of the story. There are more automations used in the General Manufacturing and Life Sciences sides of the TEC than shown here, however the ones on this page are the most interesting use cases.

For more context on our new TEC demos, visit this Youtube playlist which has video walkthroughs of each station.

General Manufacturing Automations

Change Work Order Status

This automation runs in place of triggers across all three of the assembly cell apps that would constantly track the progress of the work order. Instead, this automation maintains the status of the work order based on related units. It checks the status of a work order as the work order table is updated, and then continuously compares the status to related units at each of the stations in the assembly U-cell to determine and then update the location status of the work order.

Station Activity History

This automation logs a record when a station changes status so that management can look back at the history of a particular station. The three status’ of a station is IDLE, when a station is not being used, RUNNING, when someone is actively using the demo, and STOPPED, when an andon alert is triggered at the respective station. You can see the stations live on the GM Dashboard. Triggering when the “Stations” table is updated, this automation will determine the new status of the station, the time of the start and end of the status change, and how long the station was in a particular status for, logging all of that information into the “Station Activity History” table.

Empty Kanban

This automation routes a material request to the Receiving Inspection and Formlabs 3D Printing Cell when a Kanban is emptied at the inventory rack. Scanning a bin to empty the Kanban updates the “Kanban Cards” table, which triggers the automation to either add a material request to the table at Receiving Inspection, schedule a new print in the scheduling CW at the 3D Printing cell, or even write a DMG order at the Celos X test stand using an API.

Global Andon Light

This automation changes the color of the overhead LifX andon light when a station goes down. It is important because it runs in place of repeated triggers for each station that would run the LifX connector function as the Andon App is entered from another app. By checking if the status of any of the stations are changed in the “Stations*” table and then changing the light to red if any of the statuses are “DOWN,” it allows for new stations to be easily added to the ecosystem. Instead of having to add a whole new set of triggers associated with a new app and station, the station just needs to be added to this table and then the light will function correctly as long as the status gets updated accordingly in the Andon App.

Sync With ERP & SAP Order Complete

These automations are extremely important to virtually any company that has an existing ERP system (they all should!). They essentially show how Tulip can be seamlessly and automatically integrated with another ERP, in this case SAP. The “Sync with ERP” automation pulls in Work Orders from SAP and automatically adds them to the “Work Orders” table in the “Assembly Execution App,” so that new work orders that come in through SAP can easily be selected and worked on via Tulip player. The “SAP Order Complete” automation checks if a work order status is changed to “complete” in the “Work Orders” table, and then changes the status of the work order in SAP to reflect this.

Sync with ERP

SAP Order Complete

Schedule Completes Request

This automation is essential to the story of TEC 2.0 and shows how a group of Tulip apps can be built cohesively to solve multiple problems at once. After a 3D printed part runs out at the inventory rack, a request is sent to the 3D Printing Cell, the request is scheduled to be printed, and then printed during the scheduled time. This automation checks if the part is finished printing, and if it is, moves the finished 3D printing request to the “Material Request” table at the Receiving Inspection station, where the part is processed and then replenished at the Inventory Rack. It allows for parts to be automatically used, requested, and replenished, three things which are essential for a cohesive assembly process.

Location Update

This automation is important for showing that Tulip is capable of updating information to keep it consistent across many aspects of your ERP. It checks if any table record is updated in the “Locations” table, which tracks which material is located in which bin in the inventory rack. If the material’s location changes, the location is also now changed in the “Kanban Cards” table as well as the “Manufacturing BOM” table. It is necessary for a change in location to be reflected across all three of these tables to ensure the inventory rack functions correctly, and this automation allows for you to only have to change the information in one of them.

Life Sciences Automations

Bulk Sample Status

This automation sets the status of bulk samples to “completed” at the Laboratory Companion demo once both of the test samples status’ are set to “completed” or “disposed.” The bulk sample is only considered completed once both the pH test and UV-vis test are passed which is what both of the test samples represent. This is important because the main Bioreactor flow has composability, so the automation runs in place of triggers that would have to be added to multiple apps that would constantly check the status of the test samples and compare them to the status of the bulk sample.

Sample Result Release

This automation is important because it again shows how a system of apps built in a composable way can easily communicate with each other. It sends the data from test samples from the Lab to the Bioreactor Production facility once they have been approved by the lab manager. It ensures that the pH test and UV-vis test data are not sent until it is confirmed to be correct so that defective insulin is not harvested. It is triggered when the “Samples” table is updated, checks if the bulk sample is approved and not disposed, and then sends the data to production while logging the inspection results.

Asset Status on Procedure Date

This automation sets the status of of lab equipment to “Maintenance” when the equipment action due date is past due. It triggers when the “Equipment Actions” table is updated, checks if the due date is less than the current time, and then tells an operator that they need to perform maintenance but updating the “Assets” table. This automation is a rare example of a great real life use case in the TEC. It may be a generic problem, however scheduling maintenance of equipment and notifying operators is a core aspect of every type of manufacturing.

Hourly Maintenance Due Check

This automation is set to run once every hour, checking when maintenance for equipment is due and then changing the status to “Maintenance” if so. This is very similar to the above automation, displaying a great use case, however this is set to trigger based on a timer instead of when a table record is updated. This is important because it shows how automations do not exclusively run when someone interacts with a Tulip app or table, but can also be done completely independently. The use-case for this automation would be equipment that must be calibrated on a schedule.

2 Likes