Why is MIC digital twin CAUSAL? A gentle technical explanation

“MIC” digital twin = Multichannel IoT Causal digital twin. We will touch on the pure concept of Causality and discuss somewhat technically why MIC digital twin is indeed a “causal” solution . . . in that MIC digital twin provides the cause-effect “linkages” and weights between the multiple channels of IoT; this is applicable to ANY IoT use case where "sensors" are placed at end points that have some relationship which is to say, almost any IoT application.

System identification is an important topic in Systems Theory. Using state-space model and Kalman filter and other recursive methods, the underlying system can be identified optimally from measured data. “States” in the state-space model comes in two basic varieties –

1.??????States provided by a “physics-based” a-priori model of the system and its values estimated from measured data.

2.??????States identified and estimated from measured data.

In the first case, prior knowledge of the data-generating process or assumptions imposed on it leads to State definition. Often, these assumptions are idealized and oversimplified and do not reproduce the nature of the system correctly.

In the second case, States identified from the data while explaining the measured data well (good fit) may not have any physical relevance!

By Causal Inference approach, we are attempting the following:

• From observational data, determine the data *generating* model.

Knowing cause and effect among entities makes it a “mechanism” whereby we have a data *generating* model in hand; we “crank” the causal model and we generate data from the underlying system at will!

Let us back up a bit . . .

‘From a given definite cause an effect necessarily follows’ – so said Spinoza. David Hume (1711–76) took a much more careful look at causality and found that “regularity” is sufficient for causality – one event following the other! Hume was not being daft . . . he has weighty arguments for it but added other conditions to “regularity”. Constant conjunction seems to nail down Causality; but no, he added temporal priority and contiguity. (I am stating terms without defining them but for our purposes, common English sense will suffice).

John Mackie (1917-81) tried to tie it all together thus –

[a cause] is an insufficient but non-redundant part of an unnecessary but sufficient condition [for the effect]: using the first letters of the bolded words, we have “inus” condition tying Cause and Effect together.

Another interesting and relevant (to IoT) concept is the “Counterfactual dependence test of Causation”. Some consider it more than a “test”; they say causation itself consists in counterfactual dependence between events.

Counterfactual simply means ‘contrary to the facts”. A person takes a pill and headache is cured; if the person had NOT taken the pill (which is contrary to the facts of this case), would the headache have disappeared? This is a counterfactual “test” or thought-experiment.

Randomized Controlled Trail (RCT) for drug approval is a counterfactual test. A random group is gathered, split into 2 groups; one is given a treatment (“treatment group”) and the other is given a placebo (“control group”). That the treatment group’s disease burden reduced is nice but the counterfactual treatment (= NO treatment) given to the control group without resulting in disease burden reduction is key to concluding that the treatment CAUSED the disease burden to be reduced! Here is a case where the counterfactual experiment is real and interventional (placebo given to the control group) and not a thought-experiment . . .

In IoT situations, one can safely assume that RCT is almost never possible nor practical nor ethical, etc. This is because we cannot rewire one half of the factory floor to do one thing or close traffic in one half of the city or not treat the smoke-stack for carbon capture for long periods for statistically valid experiments to be conducted!

There is much more philosophical literature on the subject of causality – for example, energy-transfer definition of causality (cue ball transfers energy to the object ball on a pool table and hence the cue ball is the cause). In fact, there are quite a few more theories of Causality and one “Pluralism” theory which says that all theories of Causality are deficient (they all have exceptions) and hence use them all – disjunction of all the existing causality theories!

You get the flavor – Causality is not a simple concept. When a definition of Causality is so elusive, we can expect that quantifying and measuring it are not going to be easy tasks either! However, Causality is the most important relationship in the Universe . . . so we have to try.

To set the right expectations, it is unlikely that Causality or Causal Factor will be as easy as a population parameter (mean, variance, etc.) or a statistic (second-order correlation, etc.) estimation! Nor is it conditional probability (Probability of Headache Relief given Pill is NOT a causal estimate).

Let us confine our gaze to the limited realm of Internet of Things and dive deeper into what exactly Causality may be in this context and understand what allows us to measure causality with all the definitional difficulties we just saw.

Causality in IoT

With metaphysical aspects of Causality behind us, let us use a definition of causality for our “engineering” IoT use case simpler than the “inus” condition (but agree that inus condition is implicit).

Causality: “X causes Y” means that changing X alone changes Y

My favorite picture to dive deeper into causality and differentiate it from correlation in figure 1.

Figure 1. Correlation is not causation

(A) pushing causes the truck movement. Clearly, (A) is also correlated with truck movement – his Push and truck Movement are correlated. From these two observations, we can conclude the following:

·??????Causation is Correlation PLUS something else.

·??????There is NO Causation WITHOUT Correlation.

The last statement means that Causation implies Correlation – but by how much? In the figure 1, is the correlation between ‘A pushing’ and ‘truck movement’ = 1? No; the truck may move due to a strong gust of wind . . .

For the moment, assume that there are NO other external factors affecting the situation in figure 1. If all associations other than pushing are ruled out, correlation between ‘push and ‘movement’ is indeed “1”!

You can visualize the scatter plot between ‘push’ on the x-axis and ‘movement’ on the y-axis in your mind . . . all data points lie along a straight line (assuming a linear relationship) and the slope of that line is the regression coefficient that allows you to calculate/predict ‘movement’ given ‘push’.

In this case where correlation is ONE, regression coefficient IS the measure of causation between the cause and the effect, which we call “causal factor’, “causal weight”, “link strength”, etc.

As we go further into more complex IoT multichannel time series cases, you will see that regression coefficient plays a major part – the simple example considered above ought to help ground your intuition as we go forward.

SVAR model and Causality estimation

First, we will build on our understanding of regression coefficients as causal factors in the previous trivial case to very general multichannel data analysis schemes. Then only we will bring in the assumptions of “causal graphs” that will generalize causal estimation for any multichannel (and other) system.

We model multichannel IoT time series as a Structural Vector Autoregressive (SVAR) model:

For a multichannel timeseries, yt?-

The matrix elements, “s”, are the “regression” coefficients in equations (2) and (3) above. Color coding is such that Structural causal factors are BLUE and Lagged causal factors are GREEN (we will discuss why they are the causal factors presently).

A diagram corresponding to equations (2) and (3) is shown below (without error terms).

Figure 2. Simplified SVAR model signal flow.

The horizontal dotted lines in figure 2 are time indexes; [n] at the top; past data at [n-1], . . ., are stacked at the bottom. Considering the current time index, ‘n’, and equation (2) and (3),

·??????Structural causal factors from y2[n] (solid BLUE arrow top) and Lagged causal factors from y1[n-1] and y2[n-1] (2 GREEN arrows terminating at y1[n]) affect y1[n].

·??????Similarly for y2[n].

·??????y1[n] affecting itself is not allowed – NO self-causation; shown with a RED cross.

·??????The dotted BLUE arrow from y1[n] to y2[n] has a question mark – this will be discussed later.

We can re-draw figure 2 as a traditional causal graph (figure 3).

Figure 3. Causal graph of simplified SVAR model.

All the color coding and comments remain the same as for figure 2.

Regression coefficients are Causal Factors!

We saw earlier that this sub-title may be justified when we discussed figure 1 under an idealized case. Here we will generalize by considering a single channel, total number of lags, D=1, case of the SVAR model equation in (1).

As we observed at the outset, “Causation is Correlation PLUS something else.” It turns out that if we make certain assumptions, SVAR coefficients can be interpreted as “Causal Factors”.

Assumptions that elevates certain Correlations to CAUSATION:

1. Acyclic: No cycles in the corresponding graph
2. Markov: All associations between variables are due to causal relations
3. Faithfulness: Causal influence is not hidden by coincidental cancelations

They are from the works of Pearl, Spirtes and others in the last two decades. What they do is restrict the graph in figure 3 to a “DAG” – directed acyclic graph.

DAG assumption does not allow self-causality (which is logical) but also NO other loops. This is why in figure 2 and 3, I have a question mark – only ONE ?can be non-ZERO.

Estimating SVAR coefficients properly

At a high-level, Multichannel IoT Causal (“MIC”) digital twin ALGORITHM involves:

SVAR, ICA, LiNGAM, Blind Signal Separation (sometimes known as “cocktail party” problem) have celebrated history and significant theoretical underpinnings. There are fast (even fixed-point) algorithms, free Matlab and Python code and other support widely available. This work has matured nicely over the last 20 years.

Our opportunity here in IoT is to translate the existing research and applications appropriately for IoT use cases and exploit the value it brings as indicated in the picture below. The right-hand side is waiting for MIC digital twin implementations . . .

Dr. PG Madhavan

Seattle, USA

https://www.dhirubhai.net/in/pgmad/

#causality #digitaltwin #causaldigitaltwin #micdigitaltwin #iot #iiot #rootcauseanalysis

?