1. 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.

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.

2. 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 here: https://ilabo.atlassian.net/wiki/spaces/LW/pages/1795424257/Draft+Working+with+signals+and+rules#Advanced-format

3. Improved Root Cause finding algorithm and new Work Spectrum view
You can read about the root cause finding algorithm improvement on a dedicated page:
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:

4. 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:

You can read more about it in the updated documentation: Pre-Processing Functions ✔️

5. Custom short performance duration lets you specify what production time period should we take into account when the short performance value is calculated.

6. 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)

7. PackOS supports now 9 languages! YEAH!
The new version includes various fixes and extensions in translations.

8. 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 ✔️
Stay tuned for January release

9. 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)

10. Documentation improvements
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 ✔️

• Importing Orders ✔️

• Pre-Processing Functions ✔️

• Working with signals and rules [Draft]