Product Updates - August 24, 2023

Overview of Changes

Cookbooks: Best Match Algorithm

Operator CoPilot recommendations are now available even when recipes do not exist for current conditions. A new best match algorithm determines the closest recipe to current conditions and notifies you that the best match algorithm was used in addition to surfacing the conditions that were changed to retrieve a recipe.

Best Match Algorithm Example

In this example, there are two conditions other than the Product: Humidity and Supplier. Humidity is a continuous condition and Supplier is a categorical condition. The Cookbook was created with the following recipes:

Unfortunately, the condition of 80% - 100% Humidity with Supplier A has never been seen before, and therefore there is no exact match recipe recommendation. In order to provide a recommendation, the best match algorithm assigns penalties to each of the available recipes to determine the closest match.  

• Continuous condition penalties are normalized on a scale of 0-1 based on the number of possible changes. In the case of Humidity, there are 3 ranges with 2 possible changes for any given condition:
  • 80% - 100% -> 50% - 80% results in a penalty of .5 (1 / 2 changes).
  • 80% - 100% -> 0% - 50% results in a penalty of 1 (2 / 2 changes).
• Changes in categorical conditions each result in a penalty of 1. In the case of Supplier, a change from one Supplier to another results in a penalty of 1.
  • A -> B results in a penalty of 1.

Looking at the possible best matches for 80% - 100% Humidity with Supplier A, it is apparent that the best match is the 50% - 80% Humidity with the Supplier A recipe, which only receives a penalty of .5.

You would be notified that the best matchalgorithm is in use and that the Humidity condition was changed to retrieve a recipe.

Additional Notes

• The best match algorithm does not consider the Product condition.
• If any conditions are set to Auto Adjust to Current Value, the best match algorithm does not run.

Calendar Shortcuts: This Shift and Last Shift

Note: This feature is for preview only.

Creating morning meetings or shift change dashboards to monitor differences from one shift to the next is now easier using the This Shift and Last Shift shortcuts.  

Prerequisites

At this time, the following shortcuts require a data foundation that meets the following criteria:

• The shift schedule must be on a regularly repeating cadence. This kind of shift schedule is generally used in conjunction with a Shift Scheduler operator. While this is not required, using a different method of generating shift data can cause inaccuracies due to two different sources of truth existing.
• To use the exact examples below, the shift schedule must contain a single period and a single rrule. If you have more than one, you can use the examples below as a baseline, but know that you must modify them to accommodate multiple entries for those items.

Creating a Shift Schedule Table

The first thing you must do is create a Table, through the Data Dictionary Tables dev page, that contains the shift schedule. The date picker shortcuts use this table to determine which shift is currently active and which preceded it. In addition, a Shift Scheduler operator uses the table to generate matching shift data in the pipeline. The contents of the table are the information that is needed to configure the Shift Scheduler operator and an additional column that indicates which machine the schedule applies to.

Note the following:

• The machine column can contain multiple machines separated by a comma. (The comma will be changed to another separator in a future release.)
• Remember that the dtend and dtstart indicate the first occurrence of the shift, and they are only a few hours apart (the dtend is not the current time). It is best to have this start on the day before the earliest message in any RawQ Topic that this shift data will be blended with, which will create shift data that can be forward-filled onto other data without generating months of unused events before the first RawQ message.
• To be used with the operator configuration below, your shift schedule table must contain columns with these names. If you have a different column name, remember to change the name that is called by the operator.
• The column order does not matter.
• Remember to include the second header row if you are using the Data Dictionary Tables dev page.

The following provides a CSV example:

The following is the same example in table form:

After you generate a CSV that contains the shift schedule that you need, upload it to the Data Dictionary Tables dev page. Remember to select the correct workspace.

Configuring the Shift Scheduler Operator

To ensure that the shift data inside the pipeline matches how the date picker shortcuts are interpreted, use the shift schedule table to configure all Shift Scheduler operators as dynamic operators.

Note the following:

• Replace my-machine-name in line 3 with the machine name that this Shift Scheduler applies to. This value must be equal to the value of a cell in the machine column of the table.
• If you have a single Shift Scheduler operator that applies to the entire facility, and you do not need to filter out a specific machine, you can replace line 3 with {% for row in tables['shift_schedule'] %}.
• Remember to replace any column names that are different in your table. For example, if your name column is shift_name, line 5 becomes "name": "{{ row['shift_name'] }}".
• Remember that if you need more than one period or rrule, you must modify both the table and the operator configuration to match.

Turning On Shift Shortcuts in the Feature Toggle

To enable the feature, go to the feature toggle, and then turn on the Relative Shift (experimental don’t use) toggle within the APPLICATIONS section.

ODBC Connector

Note: This feature is for preview only.

Leverage your Manufacturing Data Foundation across enterprise applications with a new ODBC connector. The ODBC connector automatically generates read-only views of your production workspace’s data foundation available through the ODBC connector.

Creating the Read-Only View

The read-only view is created after you set a workspace as production. For existing production workspaces, you must switch between workspaces to activate the view. To do this, set another workspace to production, and then flip it back to the previous production workspace.

Configuring Your Connection

Use your favorite enterprise tool that supports ODBC integrations. The following example uses PowerBI: 

1. Under the More section, click Get Data, and then click PostgreSQL.
2. Type your Server and Database, and then click Direct Queryas the connectivity mode.
   1. Server: {sightmachineURL}:5432
   2. Database: tenant_storage
3. Type your user name and password.

Viewing Results

You now have read-only access to views of every underlying table for Cycles, Downtimes, Parts, and Defects. 

Note the following:

• Tables are separated by Machine Type so you have a cycle table for each machine type. 
• Table names are named by {model}_{machine_type}. 
• The column names in the views are the display names that are available in the Sight Machine platform.

Updates/Fixes

• You can now create Cookbooks without selecting a Product Type.
• An issue in which time offset chips do not move when you drag machines has been resolved.
• An issue in which the Jinja operator was not correct in the Merge workflow has been resolved.
• Workspace Drafts now include Hash (not just revision_id).