Info |
---|
When customers can expect this release: Group 1: March 3 Group 2: March 4 Group 3: March 12 |
Table of Contents |
---|
Bug Fixes:
CS-1176 - Bailey - Downtimes missing following server movePlant
...
Info |
---|
Closed The issue is not reproducible |
Downtime Pareto Updates:
...
...
PNE-670 - Plant Meeting values are not matching Shift Line
Description
Plant Meeting Cycle, Expected Production and values in Micro Stoppage and other states other then Running are not matching with Shift Line
Tip |
---|
Fixed QA tested and no longer reproducible after code fix |
...
Downtime Pareto Updates:
Prevent the same filter from being picked twice (i.e. see comment from #1000 level1=jobFilter2&level2=jobFilter3&level3=jobFilter2)
Fix for occurrences/durations for states shown with no reasons (i.e. Idle, Slow Running, Micro Stoppage, etc...)
Setup Exceeded should be shown (would be shown when this state has occurred in the same places Setup is shown in Pareto)
No Job in the hour, the respond is blank → should be ‘No Job Recorded’
Not showing reason for part of the hour where there is no job
...
Original requester:
Jesse on behalf of MDLZ
Customer Description
The ability to select which lines to show or hide under the plant view since some lines, due to complexity, are configured in SLX but data is not used for site consolidation.
For multi-category big plants (i.e. Curitiba) provide the ability to see lines based upon individual category. Possibly with a selection option (i.e. plants within a plant).
Settings to configure Line specific & KPI specific targets for each gauge for example Line 1 targets for GE gauge R-Y-G ->60%-70%-75% vs. Line 2 targets for GE gauge R-Y-G ->70%-80%-85%. Similar ability for other gauges on this view such as Rejects/Scrap.
Summary of Deliverables
Phase 1 Deliverable Functionality | Phase 2 Deliverable Functionality |
All lines within an area will be displayed as specified in mock-ups below. View will include GE and Reject gauges | The ability to select which lines are shown and hidden. (cross product) |
| See multiple categories of plants if they exist within the larger plant. (need to double check functionality, weighting?, rollup metrics?) |
Gauge targets configurable for the overall view (not line specific). | Line specific targets for each gauge. (cross product, to confirm just line specific, not job specific?) |
Purpose and Intended Audience/Use
To provide a plant level Whiteboard report that shows various overall metrics for each line within a plant. Designed to provide insight into the performance of an entire line and to compare multiple lines on a single server. The ability to sort in order of various metrics for each line will allow for customization of the report to meet plant specific needs and more robust comparison/reporting capabilities.
Scope and Overview
The enhancement will contain a single new report for each Shoplogix server that will be available for each configured line on the server. The report will not be available at the machine level due to the data used and it will make use of already available metrics and will not contain any new or modified calculations.
The report will include basic navigation/menu features that are common to other Shoplogix reports including a Home Button in the top left corner, a gear icon signifying a menu of different options (specified in further sections) and a navigation menu that will take the user to other line level views. Offsets and time periods selected will also be respected when navigating to and from the view. Mouse-over descriptions will also be available for all components within the view. Clicking on the title of any line within the view will take the user to the Line Summary view for that line. The new report will also be available as an icon in all line level navigation menus as well as the home navigation menu on the Shoplogix Tree View at a plant level. It will also contain translation capabilities for multiple languages and customer specific terminology similar to other Whiteboard reports.
Enhancements for the report will be akin to other reports with changes and issues subject to review by the Shoplogix Product Team prior to escalation and the dedication of development time. Support for any customer issues with the report will follow the same procedure as other cases, escalating according to internal customer policy prior to being reviewed by the Shoplogix Support Team who will determine the course of action to alleviate the issue.
Items mentioned in the Customer Description section that are not addressed in this specification will be included in Phase 2 of enhancements after the view has been tested and is in use on live Shoplogix servers.
Functional Requirements
User Interface
Shown below is a mock-up view of the Plant Level Line View and a diagram describing the functionality of each portion of the view:
...
Gauge Settings
Basic sorting functionality for each gauge (such as GE high to low, Reject percent high to low etc.) will be included to order the lines based on their performance for each gauge. Users will have the ability to turn gauges on or off to a maximum of three gauges and a minimum of zero gauges. Available gauges will include GE, Reject and Cycle Time. MTBF capabilities are to be added when the MTBF gauge enhancement is added to the Whiteboard. Gauge target settings will be customizable for the overall view and these settings will apply to all lines within the view.
Menu Options
The search bar shown in the first mock-up will allow the user to take advantage of filtering functionality available in other Whiteboard views. This will allow for certain downtime reasons to be isolated or excluded from the view (such as blocked or starved) via a series of commands specified by the pop-up menu, similar to other Whiteboard views. This functionality will only affect the pareto charts within the view, all other settings will remain the same.
If there exist multiple sub-plants within a larger plant they can be selected to show lines specific to that sub-plant in the tree view but selecting the overall plant will simply show each line from all sub-plants in the order they appear in the tree menu by default. The ability to filter out lines or label lines based on sub-plants within larger plants will not be included in this round of enhancements.
The default settings for the view will be to order each line based on the tree level view and set the default time period to the past 24 hours going backwards from the beginning of the current shift. Menu options will allow the user to order lines based on GE, Rejects and Cycle times; specify the time period shown; adjust gauge settings; and change the display as outlined below:
...
'Percent' is redundant for OEE Target and Scrap Target;
Offset should be respected when navigating to Analysis (shiftrollup), Chrono (shiftchrono), Layout and Line Summary (when clicking on Line title);
OEE (GE) should replace Goal as option in Sorting, Target (Goal Target = OEE Target) and Guages (Hide Goal = Hide OEE).
...
Plant Level Line View Specification V7
...
The scope states that there will be one report per server. A server can host one or many plants, and although it is implied, can you please ensure that the reporting will allow reporting by plant and 'plant within a plant' etc.?
ADD EXAMPLE
On the Functional Requirements screenshot for the Plant Level Line View, the header shows E4 CDM – Nov 3rd 2019, 06:00 – Nov 4th, 06:00. would this show the plant and or 'plant within a plant' rather than a line?
...
Correction of Line OEE Unit Conversion and Cycle Factor Issues
Unit conversion - full stack
the counts from the EOL machines and the rates from the BN machine are not being converted to line units. The issue with this is that the base units for most BN machines is something like cookies and the base units for EOL machines are usually cases, pallets, bags, etc. So you'd need to convert them to line units which will always be a weight (KG or LBS) this way you're comparing weight to weight in the numerator and denominator of the shiftline view.
Cycle factor respected if job from bottleneck is taken from the past
In this case if the job on the BN exists outside of the query period, the job is still stitched forward and the rate is used at the correct intersection point but the cycle factor of that job will not be pulled into shift line. Ideally it would be pulled in so the rate matches that of the BN machine.
...
Downtime search function for Linesummary view
Goal:
Line summary view will get a search bar at the top to allow users to filter downtimes displayed
Approach:
when user types into the search bar, the search handler will update the splat.search with URI encoded string and update the url
on render, the view will utilize the search.js with decoded splat search to pass the filtered downtimes to the children components. This will allow the children to be as simple and modular as possible.
Risks:
the users want to be able to search through ALL downtimes and display only the top 5 of the filtered data. This is different from getting top 5 downtimes and then filtering through.
Therefore this requires backend to return all downtimes.
the decision need to be made to either get rid of TopCount function from backend completely or apply a default value and keep TopCount function.
ignore capacity downtimes feature is kept and should be applied before applying the search commands
Notes:
the users want the search to be shown up in the URL so they can share it with each other.
This will have the same interaction as any other splat settings with caching.
when the user opens the new link with search splat, the search bar will not automatically show the search string / command. This is the current expected behaviour. If they want that to change, it will need a new enhancement request.
...
Line OEE calculation changes for line summary
Goal:
Two linesummary queries currently just use the line machine's oee. It needs to be changed so that when the requests are made, it will use line oee calculations instead.
in the returned data of api/linesummary/currentshift?areaid=2 also return total and scrap of the line.
Queries:
api/linesummary/prevshifts
api/linesummary/currentshift
Expected Output:
oee of each shift data should use line calculation instead of line machine's oee
oee of currentshift output should use line calculation instead of line machine's oee
**Note as per standard JSON output values of 0 will not be outputted (this is also true for nulls)
Expected Output of scrap:
Code Block |
---|
currentShift: {
shiftName: “Day”,
oee: 0.77,
startDate: “20200220T070000.000“,
endDate: “20200220T190000.000“,
scrap: 1337,
total: 9001
} |
...
New Settings Options for LineSummary view
Goal:
Adding the following UI settings to the linesummary view
Apply layout data or not to the doughnut component
Hide Goal gauge
Goal targets
Shift statistics from shiftpace view (Uptime, Remaining, Elapsed, and Production)
Approach:
Mock up can be found in the epic's spec.
Layout View option will lead to following behaviours
GRID: do not pass the layout data to doughnut component even if received from backend
Layout: same as current
Hide: skip rendering the doughnut component completely
Hide Goal: just a boolean setting to skip rendering in the gauge. Leave empty space if hidden.
Goal targets will be applied to the SummaryGauge component, which currently receives it's default goal target values from the store. Strip the default target values out of the store, and merge the target values from the setting / splat with the data from getCurrentShiftSummary() in the render function to create a new "dataset" prop object. This will leave the child component (SummaryGauge) untouched.
Copy and Pasta SHIFT STATISTICS sections of the code from shiftpace view. Once the settings are done, passing the values to the children components will be done automatically due to splat passing that's already implemented.
Risk:
when the doughnut is not rendered in, create an empty space equivalent to the space that the component would have taken. Follow up cards will be made to deal with the spacing.
Use "Hide Goal" (same as other views) instead of "Hide OEE" (as stated in the spec) for consistency that can be dealt with translation function. Same goes to "Goal Target" instead of "OEE Target"dataset prop of SummaryGauge still require a percent value for the targets (which is omitted for this view). Include a default value of 1.
Enabling extra data from SHIFT STATISTICS will make doughnut display even smaller text than before. This will be dealt with in the future.
...
Important Note on Scrap Edit
Note |
---|
Customers in Groups 1 and 2 are using the updated Scrap Edit dialogue box. Customers in Group 3 are still toggled on the OLD scrap edit dialogue box. However, IAC servers in Group 3 ARE on the new Scrap Edit dialogue box. |