Working with signals and rules [Draft]

Data Source

Both equipment and users have knowledge about the factory, it can be either a counter value, a machine alarm or a current thermostat setting.

In PackOS we call these parameters ‘signals’, they are constantly being observed and processed to determine what’s currently happening on the shop-floor.

Our edge component - LogiX Gate - is a listener designed to handle many communication protocols in parallel - OPC, HTTP, SQL, listen for value changes and send them to our cloud-based processing.
LogiX Gate will buffer all messages if connection is not available, and send them as soon as it’s back.

LogiX Gate sends messages in batches of configurable size, below you can see an example message consisting of 3 signal value changes:

[
    {
        "NodeId": "s=Filler_Counter",
        "ApplicationUri": "OPC1",
        "Value": {
            "Value": 100,
            "SourceTimestamp": "2021-04-30T00:03:20.917Z"
        }
    },
    {
        "NodeId": "s=Filler_Counter",
        "ApplicationUri": "OPC1",
        "Value": {
            "Value": 110,
            "SourceTimestamp": "2021-04-30T00:03:31.026Z"
        }
    },
    {
        "NodeId": "s=Capper_Alarm",
        "ApplicationUri": "OPC1",
        "Value": {
            "Value": 1,
            "SourceTimestamp": "2021-04-30T00:03:31.026Z"
        }
    },
]

Before the main processing, each signal can be transformed and/or augmented using PackOS pre-processing functions: Pre-Processing Functions ✔️

Machine model

Regardless of the technical details of gathering data from the factory, a machine is modelled in PackOS as an asset with pre-defined set of:

• Signals

• Properties

• State definitions

• State Rules

Signals

Each signal is identified by its Name. It’s an identifier which needs to be unique in the context of a machine, important in rule execution (see below). It should not contain any spaces or special characters, and cannot be changed after the signal is created.

To display a more user-friendly name, use signal Description

Signal Type control the meaning of the signal value:

• SIGNAL - a default value having no meaning, the signal can be used in rules to control the state of the machine

• NOPROCESSING - makes the processing skip this signal, it’s value is not being tracked

• COUNTER - is used as a good product count, its Unit field sets the machine production unit. Currently, only a single good counter per machine is allowed

• WASTE_COUNTER - defines a waste product count. There can be many waste counters on a single machine. Its Unit can be different than the one of the COUNTER - PackOS will make a conversion using an active packing structure.

• SHORT_PERFORMANCE - used to track current performance value. It's calculated automatically from the COUNTER. There should be only one signal of this type per machine. Unit defines how the signal is being calculated (e.g. car/min) converting the production unit from the Counter unit using an active packing structure and appropriate time denominator.

• [tbc]

State Rules

State rules control a current state of a machine, there are two possible formats:

• Simple format, which allows for very simple rules checking signal values

• Advanced format, which can be used for more advanced rules

Both formats can be used simultaneously for different rules on a single machine.

Simple format

The simple format uses the following syntax:

(Name Equals AlarmOne && Value Equals 1) && (Name Equals AlarmTwo && Value Equals 0)

[tbc]

Advanced format

It allows you to write arbitrary C# expressions returning true or false.
Before writing a rule, you need to decide if the rule is time-dependent (which will allow you to use Now) and check for example if last signal timestamp exceeded some duration.

An example rule looks as follows:

Signals.GetCurrentValue<bool>("AlarmOne") && !Signals.GetCurrentValue<bool>("AlarmTwo")

The following variables are available:

• DateTime Now - Current Date
  Current UTC date (Read more...)
  Only available if the rule is time-dependent

• SignalDictionary Signals - Signal Dictionary
  A dictionary of raw machine signals, holding the current and previous value.

  • string GetCurrentValue(string key) - returns last value of the signal as string

  • string GetPreviousValue(string key) - like above, but for the previous value

  • T GetCurrentValue<T>(string key) - returns the current value as the requested type

  • T GetPreviousValue<T>(string key) - like above, but for the previous value

  • DateTime GetCurrentUpdate(string key) - returns the UTC date of last signal update

  • DateTime GetPreviousUpdate(string key) - like above, but for the previous value

• CounterDictionary Counters - Counter Dictionary
  Similar to the SignalDictionary, but holds only validated counter values (after guards, resets etc).
  e.g. if raw signal goes like: 100 → 102 → 0 → 105 → 0 → 110 → 0 → 5 → 1000 → 10
  this dictionary will track only: 100 → 102 → 105 → 110 → 5 → 10

  • double GetCurrentValue(string key) - current value of the counter

  • DateTime GetCurrentUpdate(string key) - timestamp of current value update

  • double GetPreviousValue(string key) - previous value of the counter

  • DateTime GetPreviousUpdate(string key) - timestamp of previous value update

• double DesignPerformance - Current performance setting for a machine
  in production_unit / hour.
  e.g. it’s useful to compare the delay from the last counter increase to the machine performance:
  

  Counters.GetCurrentUpdate("CounterOut") > (Now - TimeSpan.FromHours(1/DesignPerformance))