Reengineered processing architecture
We’ve reengineered our processing architecture to enable much higher processing performance of our real-time data analysis engine (x1000 faster), with better horizontal scalability, better stability, and improvements across the whole platform – more about them below.
How we did it? If you’re interested, hold tight, we’ll release an article with more in-depth story soon
You’ll find performance improvements in all of the views, with dashboard or work spectrum screen loading time reduced several times. With all that increased performance, we’ve also managed to actually reduce the necessary infrastructure cost by integrating with some cool new cloud-native technologies.
Improved time-based rule execution
Improved time-based rule execution for state classification and new advanced rule editor will help you to tune the system even more and capture all necessary scenarios for machine state classification.
All old rules have backward compatibility, but now they are additionally compiled to the execution format on save which will help spot any mistakes.
Regardless of the format used, we’ve improved the execution resolution for all time-based rules, which will help reevaluate the machine state immediately after the desired condition changes. (e.g. if the rule says the work state should end 13s after the last counter, the state change will be spot on)
You can read more about the new advanced rule executor in our Working with signals and rules | Advanced-format
Improved Root Cause finding algorithm and new Work Spectrum
Improved Root Cause finding algorithm and new Work Spectrum view
You can read about the root cause finding algorithm improvement on in our 3.0 Root Cause Analysis Improvements
The work spectrum view was always mainly a tool for fine-grained analysis of situations on the line. In the new release, we’ve boosted it with a number of additional functionalities helping you better understand the history of events of line modules.
- The left sidebar lets you select a day, and a line flow you want look at.
- Work states below, as before, gives you a short summary of different statuses the line was in during that period and lets you filter through them
- Aggregation of different types of events gives you a summary of the OEE impact during that period of time, and lets you filter and see only relevant problems. After hovering on a specific event occurrence, you will see the same icon in the top-right corner of the popup telling you which type this problem belongs to.
If the machine’s short performance is enabled, work spectrum will show you any drops in performance during the work state – the bar is only full if the machine works with the target speed.
To better understand how the new root case finding algorithm works, you’ll see a small dark bars for holdups and idles on machines down / up the flow showing you what time period was searched for any root cause candidates
You can adjust the root cause search parameters in machine settings: Pre-Processing Functions.
Upgraded pre-processing which is now fully integrated with PackOS so you get it out-of-the-box (you don’t need to request an additional setup)
It allows you to write functions triggered by multiple tags, gives you better access to useful data (e.g. the current state of a machine) and supports new commands.
PackOS is also keeping track of all incoming data tags (regardless of whether they are assigned to machines) and helps you fill in the fields:
Custom short performance duration
Custom short performance duration lets you specify what production time period should we take into account when the short performance value is calculated.
Improved machine state history
Improved machine state history modifications all operations to the log of events for machines or line are processed asynchronously – the request is added to the queue of messages being received from the factory. This gives you nice properties:
- If you click ‘STOP’ on the line, the new downtime you requested will not overwrite all messages (e.g. counters) already waiting to be processed. The system will make sure that all products before the requested action have been counted and machine states recalculated, only then the operation will be applied
- You don’t need to wait until the operation is finished. Sometimes updating the log, and propagating the change to all aggregates (e.g. OEE) can take some time. You don’t need to wait for the system to complete it, but instead you can proceed with your work.
Additionally, the rules of downtimes vs counters are kept consistent. If the flag “Allow Production On Downtime” is not enabled, and you create a new downtime in the period of time when there was a counter registered – PackOS will remove this values from the total production count (e.g. to account for potentially invalid counter flashes during a changeover).
PackOS supports now 9 languages!
The new version includes various fixes and extensions in translations.
LogiX Public API and tested RapidMiner
We’re rolling out LogiX Public API and tested RapidMiner integration for any of you plugging things to PackOS data stream. Let us know if you want to take a look at our demo RapidMiner integration.
LogiX Public API is still under heavy development, but the initial version can run with PackOS 3.0, you can read more about it here: LogiX Public API
New column names in packing structure definition
Packing structure definition got a new, more understandable column names
Which helps you define how to convert between a Pallet (Parent) and Carton (Child)
Same applies for Material Master import file, make sure to download the latest version from the documentation: Preparing a Material Master Import
(Order import file has not changed)
As you’ve probably noticed by now, all our new features got their own documentation. Some of the new documentation pieces we’ve created:
Preparing a Material Master Import