Talk:Observability

Actuators

I deleted actuators from the formulation "actuators (outputs)", because in my understanding this is an error. Actuators are the inputs of a system. Apart from that i think the article could be improved. It is using non-standard mathematical notation (";"). The formulation with formally and less formally should be replaced by one proper definition (and an example if necessary).

Variables not defined

The variables C, A and O are not defined in the article. I assume the definition should the same as in the state space controls article (Maybe it should just be merged?). 76.68.248.33 (talk) 20:22, 23 November 2007 (UTC)[reply]

Question

The definition of observability in the article is about linear systems. Can anyone write something concerning observability of nonlinear systems??? مبتدئ (talk) 00:04, 26 November 2008 (UTC)[reply]

Duality

While this is not my focus area, I am curious how observability and controllability can be mathematical duals. The two terms DO relate to dual operations, observation and control, whereby an output is mapped to an operator or vice versa. However, from the page text it appears observability and controllability are measures of the two operations and therefore would be ambiguously defined as mathematical duals. Are the indices scalars? For an LTI system, it may be the case that the observability and controllability indices are equal by reciprocity. Expert review, please? Ryan Westafer (talk) 17:14, 30 August 2009 (UTC)[reply]

Typically, observability and controllability are called duals because a system is observable if the tranposed system is controllable (and vice versa). That is, to say an (A, B) system is controllable is identical to saying the (A^T, B^T) system is observable. Likewise, an (A, C) system is observable if the (A^T, C^T) system is controllable. That is, they are dual problems. Observability in the primal space is controllability in the dual space. Is this explanation satisfactory? If so, does something similar to it need to be added to the article? Or is an explanation of its significance good enough? (i.e., that being able to find an input to bring any input state to any other is identical to being able to determine an initial state knowing an output trajectory) —TedPavlic (talk/contrib/@) 15:26, 1 September 2009 (UTC)[reply]

Thanks. Yes, you explain the meaning as mathematical dual. Your explanation and a visit to the variable definitions on the state space page cleared things up. The canonical matrix 'C' was not defined in this article. With a link to State space (controls), this could be easily resolved. Ryan Westafer (talk) 00:19, 30 November 2009 (UTC)[reply]

continuous systems?

This article seems to be about discrete systems (although it's not explicitly stated, I could be wrong here), where you take n output samples, and can then predict the state of the system (if it's observable). I'm just curious, as you can also represent continuous systems in state space. Perhaps someone could add something about observability of those systems.Drugbird (talk) 08:32, 27 April 2010 (UTC)[reply]

readability

This mathematical gobblygook. Save it for the end. Not exactly laymans terms. Observability in the context of highly complex systems (like integrated circuits) is the ability to observe a change of internal state (controllability is a different, but related subject). Testability is determined (in part) by both controllability and observability .--71.245.164.83 (talk) 00:40, 12 September 2010 (UTC) —Preceding unsigned comment added by 71.245.164.83 (talk)

Estimating the unobservable??

A recent edit made Oct 10, 2012 is puzzling. It says that for an unobservable states, they might be "estimated through various means". At best, it's not clear what that means. Observability is a property of the system model, which includes the dynamic model and the measurement equations. For that model, what are the other "various means" for estimating unobservable states, other than just projecting forward an initial state estimate using the dynamic model (which you might do, for instance in a Kalman filter)? Taking the Kalman filter example: while you can get that estimate, it's usually not going to be that useful, especially in the (usual) case where the process noise is nonzero -- the variance of the unobservable states will just increase towards infinity over time. If the editor just meant that there might be other measurements not represented in a particular system, that's true but not helpful as an encyclopedia entry. That's talking about a different system model. Once a model has been picked, the measurement choices are made and only then can one talk about the observability of that system model. Gmstanley (talk) 17:25, 10 October 2012 (UTC)[reply]

Reevaluation of the statement for the row rank

Probably the statemant, that the observability of a system is being evaluated by the row rank, since actually the column rank has to be evaluated.

"if the row rank of the following observability matrix"

Greetings!Back0ut (talk) 04:26, 23 January 2015 (UTC)[reply]

Row rank and column rank are always equal (see Rank (linear algebra)#Proofs that column rank = row rank), so I don't think this should matter. That being said if the mathematics are demonstrating column rank (I haven't checked) it would be better explanation to write that you are evaluating column rank. Zfeinst (talk) 13:32, 23 January 2015 (UTC)[reply]

References

References 9 and 10 seem to be the same one.--Japarthur (talk) 05:52, 17 June 2016 (UTC)[reply]

Observability matrix reasoning for SISO systems

The section on the definition of the observability states: "Consider a SISO system with n state variables", and introduces the observability matrix as a test to see if the LTI SISO system is observable or not. The reasoning is given as: "The rationale for this test is that if n rows are linearly independent, then each of the n state variables is viewable through linear combinations of the output variables y(k).".

However, isn't the topic of discussion in that sentence a single input *single output* system? How can there be "output variables y(k)"? Wouldn't there just be one output variable y? This seems confusing and needs clarification.

Answer: While there is only one output variable, in the discrete time case (implied by the use of the "k"), measurements are taken at multiple time steps. (Hence the plural). Gmstanley (talk) 21:17, 7 April 2019 (UTC)[reply]

Suggestion to move the section "Observability in software systems" to its own article or another page

In my opinion, this does not belong here. The only linking between observability in dynamical systems and software systems is the name "observability". Saung Tadashi (talk) 16:31, 3 September 2022 (UTC)[reply]

Agreed! The core of observability is based on the behavior of mathematical models of systems, deriving conditions for it and then knowing the implications for the behavior of estimators, controls, and perhaps diagnostics based on measurements. But despite years of effort in things like provably correct programs, there doesn't appear to be much useful theory on building a mathematical model of a program so that you could then actually determine observability of the system given a set of instrumentation. One exception might be in directed graph sort of models to trace cause/effect for diagnostic purposes. That seems possible for networks and high-level module interactions if the modules are really proven to execute to some model, but probably breaks down when analyzing the software problems inside the modules, except in the case of implementation with a graphical language. But it's hard to reliably parse text languages to trace cause/effect. Do any of the commercial tools for observability in software claim they can calculate observability as a system property? If not, it's not really analytical enough to belong here.

For software, it seems like observability is really just a loosely defined conceptual term, useful mainly for marketing purposes to justify additional software tools for performance monitoring and fault detection and debugging & resolution with improved visualization and maybe some pattern matching for fault detection. But, the key is that people still have to decide what to measure based on experience and heuristics rather than selecting measurements and then being able to determine observability from a model of working software. This might not belong here any more than, say, a concept of observability for camouflage clothing. Camouflage observability could also be a useful concept, including defining metrics for observability and then advertising based on those metrics. (Although like the software case, this focuses on some numerical measure of observability rather a hard binary choice of observable vs. unobservable). In fact, it seems more likely to me that you could come up with something like camouflage observability than reliably proving observability mathematically for software. Either of those cases belong on some other page. Gmstanley (talk) 00:55, 5 September 2022 (UTC)[reply]