Input & output systems

[YingboMa]

From the discussion with @ChrisRackauckas last Friday.

It seems like controls are a subproblem of input and output systems. The outputs of controllers are inputs of original systems, while closed-loop control can be handled by inputs of the controllers as well. Various matrices relevant for linearization can be formulated in this language as well.

[cadojo]

Does this mean that the control syntax introduced in #1059 should be replaced with subsystems?

[YingboMa]

Yes.

[cadojo]

Gotcha. I hope y'all don't mind my commenting on these issues. I'm interested in helping out with features like this – I'm learning a lot by working through ModelingToolkit descriptions of systems I've worked on in my studies.

If a controller is an input-output system by itself, is there a way to specify "no equations", so it's just a pass-through system? I ask because I think there's value in being able to represent a "whole system" (connected inputs, dynamics, and outputs) with symbolic control variables, and symbolic output variables. The only way I see accomplishing this is by writing the input and output subsystems as static gains.

using ModelingToolkit

# Input "system" (no equations, inputs are passed directly through this sub-system)
@variables δₑ, δₜ # elevator and thrust inputs to a longitudinal aircraft model
inputs = NonlinearSystem(ModelingToolkit.Equation[], [δₑ, δₜ], [])

# Dynamics (the traditional ODE system that describes the longitudinal aircraft dynamics)
@parameters t
@variables x[1:4](t)
d = Differential(t)

"""Multiplies each argument by a random number, and sums the result into a scalar expression."""
random_dynamics(syms::AbstractVector...) = sum(map(x -> rand() * x, collect(syms))
eqs = [
  d(x[1]) ~ random_dynamics(x, parameters(inputs)),
  d(x[2]) ~ random_dynamics(x, parameters(inputs)),
  d(x[3]) ~ random_dynamics(x, parameters(inputs)),
  d(x[4]) ~ random_dynamics(x, parameters(inputs))
]

# Output "system" (let's assume no equations here, the outputs ~are~ the states)
outputs = NonlinearSystem(ModelingToolkit.Equation[], dynamics.x, [])

# system = connect inputs, dynamics, outputs ?

[lungd]

This looks very similar to some parts of the project I am working on.
The user can create a "MTKLayer" for (DiffEq)Flux by providing the number of inputs/outputs and a MTK system.

function InPin(;name)
  ps = @parameters x=1f0
  ODESystem(Equation[],t,Num[],ps; name)
end

function OutPin(;name)
  vars = @variables x(t)=0f0
  ODESystem(Equation[],t,vars,Num[]; name)
end

function create_pins(in::Integer, out::Integer)
  inpins = [InPin(;name=Symbol("x$(i)_InPin")) for i in 1:in]
  outpins = [OutPin(;name=Symbol("x$(i)_OutPin")) for i in 1:out]
  inpins, outpins
end

function UserDefinedSystem()
  inputs, outputs = create_pins(in, out)
  # create system
  # connect input/output pins with system variables (subsys1.x ~ inputs[1].x, outputs[1].x ~ subsys2.y)
  ODESystem(eqs, t, vars, ps; systems=vcat(inputs,outputs,system))
end

The only issue with this approach is the missing adjoint for indexing the solution with a symbol, e.g, sol[outputs[1].x]. (SciML/DifferentialEquations.jl#746)
I am not entirely sure if this could become relevant here. Sorry for the noise, if not.

[dannys4]

Talked with @ChrisRackauckas and @YingboMa on this today. What we need is to add input and output states to the systems, then decide how to handle structural_simplify and alias_elimination. Most importantly, should structural_simplify include output states?

[baggepinnen]

An output isn't really a state in the traditional sense of the word since it can be computed from other states. I rather think of outputs as functions of the state vector and control inputs, e.g., in the linear case y = Cx + Du where x is the state and u the control input.

Currently, structural_simplify removes control outputs

julia> controls(model)
1-element Vector{Any}:
 u(t)

julia> model = structural_simplify(model)

julia> controls(model)
Any[]

[baggepinnen]

This post tries to summarize how inputs and outputs are looked at from the perspective of a control engineer. I've tried to (shout out if I've failed) to represent all possible views of inputs and outputs that exist out there.

Inputs

• An input is both a forcing function and a parameter at the same time:
  • When the system is simulated in isolation it's a forcing function.
  • An input can be connected to another signal, after which it stops being an external input.
  • For (open-loop) optimal control, the input is a trainable function.
  • When the system is linearized, it's an indicator of what to differentiate with respect to.
  • When the system is inverted, it becomes an output (and vice versa).
• During simulation, an input must be connected/bound to a source, the connection may be either causal or acausal. A source can be
  • A function of time
  • An output or state of another component
  • A constant
• It's useful to distinguish between inputs that the user can control (previously called controls), and inputs that are disturbances that the user can not affect.
• The Modelica manual articulates the different notions of inputs quite well.

Ideally, one should not have to redefine the system to use the different views of an input mentioned above,
at least not redefining the dynamics equations. A nice interface for simulation of a system with an external input would be

prob = ODEProblem(sys, [u => sin(t)], (0., 1.))
sol = solve(prob, Rosenbrock23())

where u is a control input and one would like to simulate the system with a sinusoidal input.

When systems with inputs and outputs are connected together, we need to distinguish between external and internal signals. Consider the following system, where C is a dynamical system representing a feedback controller and P is a dynamical system representing a process. All lines in this diagram are arrows, indicating causal links. (P and C may have acausal structure inside).

                        d│                 n│
                         │                  │
           ┌────────┐    │   ┌────────┐     │
  r      e │        │ uc ▼ u │        │ z   ▼  y
───────+───►   C    ├────+───►   P    ├─────+─┬───►
      -▲   │        │        │        │       │
       │   └────────┘        └────────┘       │
       │                                      │
       └──────────────────────────────────────┘

A common task for control engineers is to simulate this system with different external input signals r, d, n representing reference signals, load disturbances and measurement noise respectively. All arrows are leading away from these external input sources. Note that the reference r is the only input the user has control over, the other inputs are disturbances (which may or may not be measurable). In this case, it would be natural to define three inputs r,d,n that all appear in the dynamics equations of the composite system, and simulate the system with various input mappings, e.g.,

[
    r => t >= 1 # A step in reference at time 1
    d => t >= 5 # A step in load disturbance at time 5
    n => white_noise # Gaussian measurement noise
]

To turn a signal off, one would simply supply d => 0.

A common optimization goal for the system above would be to optimize the parameters (or structure) of C, which is quite distinct from optimizing u directly. In this case, u is a function of the measurement (which in turn is a function of the state). The only functions of time alone are the external inputs r, d, n. When we simulated the system P in isolation above we defined the external input u at simulation time according to

prob = ODEProblem(sys, [u => sin(t)], (0., 1.))

this has now been replaced by the connection u = uc + d and u is no longer an external input.

If we instead consider the system P in isolation

  ┌────────┐
u │        │ y
──►   P    ├──►
  │        │
  └────────┘

the u signal is now an external input. In this case, one may wish to simulate and/or optimize an input signal u = u(t).
Ideally, the dynamical system P as it's seen here would be usable in both this simple form, where it may be simulated with u = u(t), and in the scenario above, where the input of P is connected to an internal signal (u = uc + d) of the composite system.

Modelica handles the interface between the acausal and causal domains with "one-way valves", illustrated by the arrow between the signal source and the torque block in the Modelica diagram below.

Outputs

• An output is a function of the state x and input u, y = g(x, u)
• Measurement noise is covered in the view above by adding a stochastic input to u and potential dynamics of the noise would have states added to x.
• If the state is reduced (e.g., structural_simplify), the output function changes to y = g(h(xᵣ), u) where h translates the reduced state xᵣ to the full state x.
• Similar to the case for inputs, it's useful to distinguish between outputs that are measured and outputs that indicate some kind of performance measure or controlled variable. (The term controlled variable is standard, but a bit of a misnomer, it's a variable we would like to control, but we can not directly manipulate it, it's rather an outcome of our control).

The control community typically partitions the inputs and outputs of a system P according to

  z  ┌───────┐  w
◄────┤       ◄────
     │   P   │
◄────┤       ◄────
  y  └───────┘  u

where w are input disturbances (not controllable) and u are controllable inputs, z are controlled variables (not measured), and y are measured outputs. A feedback system controlling P will thus be

          ┌──────────────┐
    z ◄───┤      P       │◄──── w
 ┌─ y ────┤              │◄──── u ─┐
 │        └──────────────┘         │
 │                                 │
 │        ┌──────────────┐         │
 └───────►│      C       ├─────────┘
          │              │
          └──────────────┘

where the controller acts on the measured outputs y through the controlled inputs u. The purpose of the controller C is to reject disturbances w such that they have minimal influence on the performance metric z. w may contain both known disturbances, such as a reference signal, and stochastic/unknown disturbances. As a concrete example of the difference between y and z, consider a servo system where we can measure (y) the position, but we are interested in controlling (z) the velocity.

Misc. comments

I’m still loosely of the opinion that putting ctrl(x,p,t) and ctrl(t) under the same interface may prove to be a mistake. The two are generally treated as separate subjects and not meaningfully interchangable. Ref

After having thought about this a bit more, I don't think the u = ctrl(x,p) interface is any different than a generic parameter-estimation problem. In the feedback loops depicted above, there might be parameters in both P and C, and any of those parameters may be optimized. If we optimize parameters of P, we call it system identification or parameter estimation, if we optimize the parameters of C, we call it controller tuning. They are largely equivalent though. Note that a lot of complexity might hide behind the boxes P and C, they may include stuff like "software/hardware in the loop" and arbitrarily complicated algorithms. Example by ronisbr

The problem of optimizing u = ctrl(t) is conceptually slightly different since we don't really want to associate the trainable parameters with the system we simulate, they rather belong to something external.

[ChrisRackauckas]

You can connect a component to an input variable to make it be controlled by parametric functions. I think this can be closed then, but @baggepinnen comment if you think there's anything more to do here.