# Relations among Open-loop Control Ability, Control Strategy Space and
Closed-loop Performance for Linear Discrete-time Systems ††thanks: Work
supported by the National Natural Science Foundation of China (Grant No.
61273005)

Mingwang Zhao  Information Science and Engineering School, Wuhan University of
Science and Technology, Wuhan, Hubei, 430081, China
Tel.: +86-27-68863897
Work supported by the National Natural Science Foundation of China (Grant No.
61273005)

###### Abstract

In this article, the definition on the control ability, and the relation
between the open-loop control ability and the closed-loop performance are
studied systematically for the linear dynamical systems. Firstly, to define
and compare rationally the state control ability between the different
controlled plants or one controlled plant with the different system
parameters, the normalization of the input variables, the state variables, the
system mdeols are discussed. With the help of the normalization, the state
control ability with the time attribute can be difined under the unit input
constraint (input amplitude limited). And then, a theorem on the relations
among the open-loop control ability, the control strategy space (i.e., the
solution space of the input variables for control problems), and the closed-
loop performance with the time attribute is purposed and proven. Based on
that, the conclusion that it is very necessary to optimize the control ability
for the practical engineering problems can be got. Finally, the simulation
experiments show us the normalizing the variables and system models, and
comparing the contol ability between the different controlled palnts.

###### keywords:

control ability , controllability region , closed-loop performance , time-
optimal control , discrete-time systems , state controllability

††journal: Journal Name

##  1 Introduction

Putting forward the concept and criterion on the state controllability of the
dynamical systems in 1960’s by R. Kalman, et al, [10] initiated a new era for
control theory. As we known, the concept can reveal deeply the possibility
controlling the state variables by the input variables and impels us to
understand and control well the dynamical systems. Therefore, the concept
became one of the most important concept to support the 60 years development
of the control theory.

It is a pity that the controllability concept is only a qualitative concept
with two-value logic and the dynamical systems is distinguished as only two
classes of systems, controllable systems and uncontrollable systems, according
to the corresponding controllability criterion. The concept and criterion
could not tell us the control ability and control efficiency of the input
variables to the state variables, and the quantitative concept and analysis
method on that are failed to establish. In fact, the quantitative concept and
analysis method are very important for the control theory and engineering and
many engineering problems are dying to these concept and method for getting
the easier controller desgin process, the better controller, and the better
closed-loop performance index. For example, evaluating the control ability and
control efficiency of the controlled plants can help us to understand and
solve the following important control problems:

1) how to choose the controlled plants or equipments (e.g., choosing DC or AC
motor for designing in some electric drive system?), how to choose the input
variables(e.g., choosing power supply of main circuit or excitation circuit as
the input variable for desiging in some DC motor speed-controller), and how to
place the location of the actuators in larger mechanical system (e, g.,
mechanical cantilever, bridge, solar panels, etc), for maximizing the control
ability of the open-loop systems.

2) how to design and optimize the structure and technical parameters of the
open-loop plants to get the more control ability and then to make designing
and implementing the closed-loop controller easily.

3) how to determine the leader, the sub-leaders, and the connections between
the nodes in the networked control systems and formation system for maximizing
the performance of these systems.

4) how to determine reasonably the expected target state or state trace, the
control horizon and the optimization horizon for these optimal control
problems, adaptive control problems, predictive control problems, and the
receding-horizon control(RHC) problems, and then the control laws can be got
by solving these control problems.

To summarize above, defining, quantifying and optimizing the control ability
are with the very greater signification for the control theory and
engineering.

In this paper, the definition on the control ability is studied
systematically. Firstly, to define and compare rationally the state control
ability of the input variables betweenthe different control plants or one
controlled plant with the different system parameters, the normalization of
the input variables, the state variables, and the system models are discussed.
With the help of the normalization, the time-attribute control ability with
the unit input variables can be defined. And then, a theorem on the relations
among the open-loop control ability, the control strategy space (i.e., the
solution space of the input variables for control problems), and the closed-
loop time performance is purposed and proven. Based on that, the conclusion
that it is necessary to optimize the control ability for the practical
engineering problems can be got. Finally, the simulation experiments show us
the normalizing the variables and system models, and comparing the time-
attribute contol ability between the different controlled palnts.

##  2 Normalization and Constraints for the Variables and System Models

In this paper, the linear discrete-time (LDT) systems is as a sample for
studying the definition and the analysis method on the state control ability,
and the obtained results can be generalized conveniently to other classes of
dynamical systems. In general, the LDT Systems can be formulated as follows:

$x_{k+1}=Ax_{k}+Bu_{k},\quad x_{k}\in R^{n},u_{k}\in R^{r},$ (1)

where $x_{k}$ and $u_{k}$ are the state variables and input variables,
respectively, and matrices $A\in R^{n\times n}$ and $B\in R^{n\times r}$ are
the state matrix and input matrix, respectively, in the system models [9],
[3]. To investigate the controllability of the linear dynamic systems (1), the
controllability matrix and the controllability Grammian matrix can be defined
as follows

$\displaystyle P_{N}$ $\displaystyle=\left[B,AB,\dots,A^{N-1}B\right]$ (2)
$\displaystyle G_{N}$
$\displaystyle=\sum_{i=0}^{N-1}A^{i}B\left(A^{i}B\right)^{T}$ (3)

where $N\geq n$. That the rank of the matrix $P_{N}$ and $G_{N}$ is $n$, that
is, the dimension of the state space the systems (1), is the well-known
sufficient and necessary criterions on the state controllability for the LDT
systems.

In papers [15], [5], [13], and [8], the determinant value
$\det\left(G_{N}\right)$ and the minimum eigenvalue
$\lambda_{\textnormal{min}}\left(G_{N}\right)$ of the controllability Grammian
matrix $G_{N}$ can be used to quantify the control ability of the input
variables to the state space, and then be chosen as the objective function for
optimizing and promoting the control ability of the linear dynamical systems.
Due to lack of the analytical computing of the determinant
$\det\left(G_{N}\right)$ and eigenvalue
$\lambda_{\textnormal{min}}\left(G_{N}\right)$, these optimizing problems for
the control ability are solved very difficulty, and few achievements about
that were made. Out of the need of the practical control engineering,
quantifying and optimizing the control ability are key problems in control
theory and engineering fields.

To study rationally the control ability of the input variables to the state
variables in different dynamical systems, it is necessary to normalize the
input variables, the state variables, and the system models. Based on the
normalization, the control ability can defined and discussed in detail.

###  2.1 Normalization of the Variables and System Models

In different practical controlled plants, the physical dimensions, scales,
value ranges of the input variables and state variables are different.
Comparing rationally the control ability of these different practical plants,
or these different input variables, firstly, the input variables, the state
variables, and then the system models must be normalized according to the
practical control problems. For example, to compare the control ability
between the two different input variables in one controlled plant or two
different controlled plants, the physical dimensions, scales, value ranges are
necessary to be adjusted as a proper compatible values with some rationalness.
Similarly, to compare the controlled ability between the two different state
variables, the dimensions, scales, ranges are also necessary to be adjusted as
a proper compatible values. Next, two examples are discussed for showing these
adjustment and normalization.

1) If only one input variable can be used to be designed the speed controller
of a practical DC motor, which voltage variable, the power supply of the main
circuit or excitation circuit, is chosen as that for maximizing control
ability? The value ranges of these voltage variables and the ratios between
the voltage variables and the speed variables of the motor must be adjusted to
be with uniformity. Based on this, comparing with the different input
variables is with rationalness and signification.

For example, if the rated values of the main circuit input variable $u_{m}(k)$
and excitation circuit input variable $u_{e}(k)$ are respectively $u_{m}^{*}$
and $u_{e}^{*}$, that is, the input variables are respectively in the rated
interval $[-u_{m}^{*},u_{m}^{*}]$ and $[-u_{e}^{*},u_{e}^{*}]$, to compare
rational the control ability of the input variables, the input variables of
the system models for the two cases should be normalized respectively as

$\displaystyle u_{k}=u_{m}(k)/u_{m}^{*}\;\textnormal{ and
}\;u_{k}=u_{e}(k)/u_{e}^{*}$ (4)

where $u_{k}$ is the normalized input variable which the define domain is
$[-1,1]$. If the system models with the two input variables are respectively
$\Sigma\left(A_{m},B_{m}\right)$ and $\Sigma\left(A_{e},B_{e}\right)$, the
normalized system models are respectively as

$\displaystyle\Sigma\left(A_{m},u_{m}^{*}B_{m}\right)\;\;\textnormal{and}\;\;\Sigma\left(A_{e},u_{e}^{*}B_{e}\right)$
(5)

2) Which motor, DC motor with the excitation controller or AC motor with the
variable frequency controller, can be determined to be used to the some
electric speed control system for maximizing control ability? The value ranges
of the input variables and the state variables, the ratios between the input
variables and the speed variable, and the power of the electric energy of the
two motors, must be adjusted to be with uniformity. Based on this, comparing
with the different controlled plants is with rationalness and signification.

For example, let the rated values of the inputs $u_{d}(k)$ and $u_{a}(k)$, the
main circuit currents $i_{d}(k)$ and $i_{a}(k)$, the speed outputs $y_{d}(k)$
and $y_{a}(k)$, and the accelerations $\dot{y}_{d}(k)$ and $\dot{y}_{a}(k)$ of
the two motors are respectively as

$\displaystyle\left(u_{d}^{*},\;i_{d}^{*},\;y_{d}^{*},\;\dot{y}_{d}^{*}\right)\;\;\textnormal{and}\;\;\left(u_{a}^{*},\;i_{a}^{*},\;y_{a}^{*},\;\dot{y}_{a}^{*}\right)$

For comparing the control ability of the two motors when the all variables in
there speed rated intervals, the input and output variables should be
normalized as

$\displaystyle\left\\{\begin{array}[]{l}\left(u_{d}(k)/u_{d}^{*},\;i_{d}(k)/i_{d}^{*},\;y_{d}(k)/y_{d}^{*},\;\dot{y}_{d}(k)/\dot{y}_{d}^{*}\right)\\\
\left(u_{a}(k)/u_{a}^{*},\;i_{a}(k)/i_{a}^{*},\;y_{a}(k)/y_{a}^{*},\;\dot{y}_{a}(k)/\dot{y}_{d}^{*}\right)\end{array}\right.$
(8)

And then, the all input and output variables are in the define domain $[-1,1]$
and the system models $\Sigma\left(A_{d},B_{d}\right)$ and
$\Sigma\left(A_{a},B_{a}\right)$ with the state variable vectors
$\left[i_{d},y_{d},\dot{y}_{d}\right]$ and
$\left[i_{a},y_{a},\dot{y}_{a}\right]$ and are transformed respectively as

$\displaystyle\Sigma\left(P_{d}^{-1}A_{d}P_{d},u_{d}^{*}P_{d}^{-1}B_{d}\right)\;\;\textnormal{and}\;\;\Sigma\left(P_{a}^{-1}A_{a}P_{a},u_{a}^{*}P_{a}^{-1}B_{a}\right)$
(9)

where the normalization matrices $P_{d}$ and $P_{a}$ for the state variables
are respectively as

$\displaystyle
P_{d}=\textnormal{diag}\left\\{i_{d}^{*},y_{d}^{*},\dot{y}_{d}^{*}\right\\}\;\;\textnormal{and}\;\;P_{a}=\textnormal{diag}\left\\{i_{a}^{*},y_{a}^{*},\dot{y}_{a}^{*}\right\\}$
(10)

For comparing the control ability of the two motors which the all output
variables are in the same expecting interval as follows

$[-i_{s},i_{s}],\;[-y_{s},y_{s}],\;[-\dot{y}_{s},\dot{y}_{s}],\;$

the input and output variables should be normalized as

$\displaystyle\left\\{\begin{array}[]{l}\left(u_{d}(k)/u_{d}^{*},\;i_{d}(k)/i_{s},\;y_{d}(k)/y_{s},\;\dot{y}_{d}(k)/\dot{y}_{s}\right)\\\
\left(u_{a}(k)/u_{a}^{*},\;i_{a}(k)/i_{s},\;y_{a}(k)/y_{s},\;\dot{y}_{a}(k)/\dot{y}_{s}\right)\end{array}\right.$
(13)

And then, the system models are transformed respectively as

$\displaystyle\Sigma\left(P_{s}^{-1}A_{d}P_{s},u_{d}^{*}P_{s}^{-1}B_{d}\right)\;\;\textnormal{and}\;\;\Sigma\left(P_{s}^{-1}A_{a}P_{s},u_{a}^{*}P_{s}^{-1}B_{a}\right)$
(14)

where the normalization matrices $P_{s}$ is as

$\displaystyle
P_{s}=\textnormal{diag}\left\\{i_{s}^{*},y_{s}^{*},\dot{y}_{s}^{*}\right\\}$
(15)

After the normalization of the system models as above, analyzing, comparing
and optimizing the control ability between the different dynamical systems are
with rationality. The above normliztion methods are also applied to other
controlled plants.

###  2.2 Constraints of the amplitude, fule and Energy of the Input Variables

The so-called state control ability is indeed the ability controlling the
state variables by the input variables. The basis for comparison is the
normalization and constraint conditions of the input variables. In fact, the
input variables of the most practical controlled plants are bounded, with some
constraints, or some with saturation element [1], [6], [7]. For example, the
power supply voltage variables as the input variables for the DC or AC motor
are bounded, and the total fuel or energy wasted in the rockets is with some
constraints. Therefore, based on these bounded values and constraints, the
input variables can be normalized.

In control theory and engineering field, the most common bounded and
constraint cases of the input variable vector $u_{k}$ can be summarized as the
two following cases

$\displaystyle U_{a,p}$
$\displaystyle=\left\\{u_{k}:\|u_{k}\|_{p}=\left(\sum_{i=0}^{r}|u_{k,i}|^{p}\right)^{1/p}\leq
U\right\\}$ (16) $\displaystyle U_{t,p}$
$\displaystyle=\left\\{U_{N}:\|U_{N}\|_{p}=\left(\sum_{k=0}^{N-1}\|u_{k}\|_{p}^{p}\right)^{1/p}\leq
U\right\\}$ (17)

where $r$ and $u_{k,i}$ are the input variable numbers and the $i$-th input
variable of the multi-input systems, respectively;
$U_{N}=\left[u_{0}^{T},u_{1}^{T},\dots,u_{N-1}^{T}\right]^{T}$. The
constraints with $p=1,2,3$ are respectively the amplitude, fuel, and energy
bounded. The condition (16) is for bounding the input variables in the all
sampling times, and the condition (17) is for constraining the total waste of
the input in a control period $[1,N]$. In fact, for the single-input systems,
the constraints (16) are a same constraint as

$\displaystyle|u_{k}|\leq U,\;\forall k\geq 0$ (18)

In practical control engineering problems, the most common constrints are as
follows

$\displaystyle\|u_{k}\|_{\infty}$ $\displaystyle\leq U,\;\forall k\geq 0$ (19)
$\displaystyle\|U_{N}\|_{1}$ $\displaystyle\leq U$ (20)
$\displaystyle\|U_{N}\|_{2}$ $\displaystyle\leq U$ (21)

These 3 constraints are bounded on the amplitude, total fuel, and total energy
of the input variables, respectively. For comparing conveniently the control
ability, the bounded value $U$ is chosen as 1, and then these 3 constraints
can be called as the unit input constraint, unit total fuel constraint, and
unit total energy constraint.

##  3 The Definitions of the Controllability Region

Similar to the definition of the state controllability region for the input-
saturated linear systems in papers [1], [6], [7], the state controllability
regions of the LDT Systems with the input constraints are defined as follows

$\displaystyle R^{c}_{*}(N)$
$\displaystyle=\left\\{x:x=-\sum_{k=0}^{N-1}A^{-k-1}Bu_{k},\;\;\forall
u_{k}\in U_{*}\right\\}$
$\displaystyle=\left\\{A^{-1}x:x=\sum_{k=0}^{N-1}A^{-k}Bz_{k},\;\;\forall
z_{k}\in U_{*}\right\\}$ (22) $\displaystyle R^{d}_{*}(N)$
$\displaystyle=\left\\{x:x=\sum_{k=0}^{N-1}A^{N-k-1}Bu_{k},\;\;\forall
u_{k}\in U_{*}\right\\}$
$\displaystyle=\left\\{x:x=\sum_{k=0}^{N-1}A^{k}Bz_{k},\;\;\forall z_{k}\in
U_{*}\right\\}$ (23)

where * indicate the case of the input constraints in Eqs. (16) and (17),
$R^{c}_{*}(N)$ and $R^{d}_{*}(N)$ are the narrow controllability regions (
a.k.a. ”recover region”) and the reachability region, respectively. By Eqs.
(22) and (23), we can see, the narrow controllability regions and the
reachability region can be transformed each other as follows

$\displaystyle\left.R^{c}_{*}\right|_{A}=A^{-1}*\left.R^{d}_{*}\right|_{A^{-1}}$
(24)

Therefore, the broad controllability region, include the narrow
controllability regions and the reachability region, can be defined as follows

$\displaystyle R_{*}(N)=\left\\{x:x=\sum_{k=0}^{N-1}A^{k}Bz_{k},\;\;\forall
z_{k}\in U_{*}\right\\}$ (25)

In fact, the reahability region $R^{d}_{*}(N)$ is identical with the broad
controllability region $R_{*}(N)$, and the narrow controllability region
$R^{c}_{*}(N)$ can be got by transformed of $R_{*}(N)$. Next, the control
ability for the broad controllability region $R_{*}(N)$ is discused and the
obtained results can be generalized to the regions $R^{c}_{*}(N)$ and
$R^{d}_{*}(N)$.

For the 3 most common constraints in Eqs. (19), (20), and (21), the
controllability regions, i.e., $R_{a,\infty}(N)$, $R_{t,1}(N)$, and
$R_{t,2}(N)$, are the biggest range of the controllable state with the unit
input constraint, unit total fuel constraint, and unit total energy
constraint, respectively.

The state controllability region $R_{*}(N)$ are as a convex geometry in
$n$-dimensional (abbreviation: $n$-D) space. Region $R_{a,\infty}(N)$ is a
parallel polyhedron and can be regarded as a special zonotope [6], [7], [17],
region $R_{t,2}(N)$ is a ellipsoid (i.e., so called ”controllability
ellipsoid” ) [4], [11], [14], [12], [2], but the region $R_{t,1}(N)$ is a
rhomboid. In the following sections, the controllability region
$R_{a,\infty}(N)$ with the unit input variable constraint $U_{a,\infty}$ and
the corresponding control ability are defined and analyzed, and other cases,
the controllability regions $R_{t,2}(N)$ and $R_{t,1}(N)$, will be studied in
another paper.

##  4 Control Ability under the Unit Input Constraint

###  4.1 The properties of the controllability Region $R_{a,\infty}(N)$

As stated in papers [6], [7], [17], the state controllability region
$R_{a,\infty}(N)$ (Short as $R(N)$ )under the unit input constraint is a
convex geometry, can be regard as a parallel polyhedron or a special zonotope.
In fact, the region $R(N)$ is surrounded by a series of vertices, edges,
2-dimensinal faces, 3-D feces, …. All vertices, edges, $i$-D faces
($i=\overline{2,n-1}$) construct the boundary of the region $R(N)$.

Some properties about the vertices, shape and size of the region can be
summarized as follows [6], [7], [17].

###### Property 1

The all vertice of the controllability region $R(N)$ can be computed as
follows

$\displaystyle\textnormal{Ver}\left(R(N)\right)=\left\\{x\left|x=\sum_{i=0}^{N-1}\textnormal{sgn}\left(d^{T}A^{i}B\right)A^{i}B,\;\forall
d\in R^{n}\right.\right\\}$ (26)

Based the vertice produced by Eq. (26), all edges and $i$-dimensinal faces
($i=\overline{2,n-1}$) can be produced recurssively.

###### Property 2

If the LDT Systems (1) is controllable, when $N\geq n$ the controllability
region $R(N)$ is a $n$-D geometry, and then for any $N_{1}<N_{2}$, we have

$\displaystyle R(N_{1})\subset R(N_{2})\;\textnormal{and}\;\partial
R(N_{1})\cap\partial R(N_{2})=\phi$ (27)

that is, the geometry $R$ is strictly monotonic expansion, where $\partial R$
is the boundary of the geometry $R$.

If the systems is not controllable, when $N\geq n$ the region $R(N)$ is a
$n_{c}$-D geometry, and then for any $N_{1}<N_{2}$, we have

$\displaystyle R(N_{1})\subseteq R(N_{2})\;\textnormal{and}\;\partial
R(N_{1})\cap\partial R(N_{2})\neq\phi$ (28)

that is, the geometry $R$ is monotonic expansion, where $n_{c}$ is the
controllability index, that is, $n_{c}=\textnormal{rank}P_{N}$.

Fig. 1 shows the 2-D narrow controllability region $R^{c}(N)$ generated by the
matrix pair $(A,B)$ as follows

$A=\left[\begin{array}[]{cc}1.1616&-0.5051\\\
-0.0505&1.6162\end{array}\right],\;\;b=\left[\begin{array}[]{c}1.8182\\\
-0.8182\end{array}\right]$

Figure 1: The 2-D zonotopes $R^{c}(N)$ when $N\in\\{2,6\\}$

Because that the matrix pair $(A,B)$ is controllable, the controllability
region $R^{c}(N)$ in Fig. 1 is strictly monotonic expansion with the increase
of the sampling step $N$.

In the next discussion, the systems are assumed always as a controllable
systems and the geometry $R$ is a $n$-D zonotope.

###  4.2 The Definition of the Control Ability

As we know, the bigger of the controllability region $R$ is, the more the
controllable states in the state space are, and then, can we say that the
control ability of the dynamical systems is the stronger or not. In the next
subsection, it will proven that for the control problem stabilizing a given
initial state to the origin of the state space (or making the initial state at
the origin to reach the given state ), the bigger of the controllability
region, the bigger the solution space of the input variables is, and then the
better the some closed-loop control performance is. Thus, the size of the
controllability region $R$ is used to define and describe the control ability.

Next, two equivalent definitions on the stronger control ability between the
two differential controlled plants, or of one controlled plants with two sets
of systems parameters are purposed as follows.

###### Definition 1

For the controllability regions $R^{(1)}(N)$ and $R^{(2)}(N)$ of the two given
LDT Systems $\Sigma_{1}$ and $\Sigma_{2}$, if the given $x_{0}\in\partial
R^{(1)}(N_{1})\cap\partial R^{(2)}(N_{2})$ and $N_{1}<N_{2}$, the time-
attribute control ability of the systems $\Sigma_{1}$ at state $x_{0}$ is
stronger than the systems $\Sigma_{2}$. If for any $N>0$, the time-attribute
control ability of the systems $\Sigma_{1}$ at all state in $\partial
R^{(1)}(N)\cap\partial R^{(2)}(N)$ is stronger than the systems $\Sigma_{1}$,
the control ability of the systems $\Sigma_{1}$ is stronger than the systems
$\Sigma_{2}$.

###### Definition 2

For any $N>0$, if the two controllability regions $R^{(1)}(N)$ and
$R^{(2)}(N)$ of the LDT Systems $\Sigma_{1}$ and $\Sigma_{2}$ satisfy

$\displaystyle R^{(1)}(N)\supset R^{(2)}(N)\;\textnormal{and}\;\partial
R^{(1)}(N)\cap\partial R^{(2)}(N)=\phi,$ (29)

the time-attribute control ability of the systems $\Sigma_{1}$ is stronger
than the systems $\Sigma_{2}$. if $R^{(1)}(N)$ and $R^{(2)}(N)$ for any $N$
satisfy

$\displaystyle R^{(1)}(N)\supseteq R^{(2)}(N)\;\textnormal{and}\;\partial
R^{(1)}(N)\cap\partial R^{(2)}(N)\neq\phi,$ (30)

the time-attribute control ability of the systems $\Sigma_{1}$ is not weaker
than the systems $\Sigma_{2}$.

According to the above definitions, the bigger the size the controllability
region $R(N)$ is, and the stronger the time-attribute control ability of the
LDT systems is. Therefore, based on the computing and analyzing the size and
shape of the geometrys $R(N)$, the time-attribute control ability of the
dynamical systems can be compared for many control engineering problems as
stated above. Except for the time-attribute control ability, based on other
input constraints, the energe-attribute and fuel-attribute control ability can
be defined and analyzed, and the related works will be carried out in another
papers.

##  5 Theorem on Relation between the Open-loop Control Ability and the
Closed-loop Performances

In this section the control ability for the unit input constraint is discussed
in detail and the results can be generalized convenient to the other
constraints of the input variables. Before the discussion, a time-optimal
property for the boundary of the controllabilty region is stated as follows
[6], [7].

###### Property 3

If the LDT Systems (1) is controllable (or reachable) and the given state
$x_{0}$ satisfy

$\displaystyle x_{0}\in R(N)\setminus R(N-1)$ (31)

the time waste of the time-optimal control problem for stabilizing the state
$x_{0}$ to the origin of the state space (or making the state at the origin to
reach the given state $x_{0}$ ) under the input amplitude constraint, is $N$,
that is, the fewest control sampling number is $N$.

Based on the definition of the time-attribute control ability and above
properties, a theorem on the relations among the open-loop control ability,
the solution space of the input variables, and the closed-loop performances
are purposed and proven as follows.

###### Theorem 1

It is assumed that two LDT Systems $\Sigma_{1}$ and $\Sigma_{2}$ are
controllable (or reachable), and their controllability regions are
$R^{(1)}(N)$ and $R^{(2)}(N)$ respectively. If we have

$\displaystyle R^{(1)}(i)\subseteq R^{(2)}(i),\;\forall i\leq N,$ (32)

for the control problem stabilizing the state $x_{0}\left(x_{0}\in
R^{(1)}(N)\cap R^{(2)}(N)\right)$ to the origin of the state space (or making
the state at the origin to reach the given state $x_{0}$ ), the following
conclusions hold under the input amplitude constraint.

1) The time waste of the time-optimal control for the system $\Sigma_{2}$ is
not more than that of $\Sigma_{1}$, that is, there exist some control
strategies with the less control time and the faster response speed for the
system $\Sigma_{2}$.

2) There exist more control strategies for the system $\Sigma_{2}$, that is,
the bigger the controllability region is, the bigger the solution space of the
input variables for the control problems, and then the easier designing and
implementing the controller are.

Proof of Theorem 1 Next, the proof will be discussed only for the stabilizing
control problem, and the obtained result holds for the reaching control
problem.

First, according to the definition of the controllability region, for the
state controllable systems $\Sigma_{1}$ and $\Sigma_{2}$, we have,

$\displaystyle R^{(j)}(i)\subset R^{(j)}(i),\;j=1,2;\;i=1,2,\dots,N-1$ (33)

So, by Eq. (32) and Eq. (33), we know, for any state $x_{0}\in
R^{(1)}(N)\setminus R^{(1)}(1)$, there must exist two finite positive number
$k_{1}$ and $k_{2}(k_{2}\leq k_{1}\leq N)$ satisfied

$\displaystyle x_{0}\in\left\\{R^{(1)}\left(k_{1}\right)\setminus
R^{(1)}\left(k_{1}-1\right)\right\\}\cap R^{(2)}\left(k_{2}\right)$ (34)
$\displaystyle R^{(1)}\left(k_{1}\right)\subseteq R^{(2)}\left(k_{2}\right)$
(35)

Therefore, for controlling the system state variables from the given $x_{0}$
to the origin, the fewest sampling steps must be $k_{1}$ for the system
$\Sigma_{1}$, but must be less than or equal to $k_{2}$ for the system
$\Sigma_{2}$. So, for the any state $x_{0}\in R^{(1)}(N)\setminus R^{(1)}(1)$,
for $k_{2}\leq k_{1}$, the time waste of the time-optimal control for the
system $\Sigma_{2}$ is not more than that of the system $\Sigma_{1}$.

In addition, for any state $x_{0}\in R^{(1)}(1)$, the fewest control times
(sampling steps) are 1 for both of the two systems, that is, the time waste of
the time-optimal control for the system $\Sigma_{2}$ is not more than that of
the system $\Sigma_{1}$.

In summary, for any state $x_{0}\in R^{(1)}(N)\cap R^{(2)}(N)$, the conclusion
1) in Theorem 1 holds.

(2) Denoting the input sequence and its solution space for controlling the
given state $x_{0}$ to the origin for systems $\Sigma_{i}$ as
$u^{(i)}_{0,N-1}(x_{0})$ and $U^{(i)}_{N}(x_{0})$, respectively. Without loss
of the generality, it is assumed that $r=1$, that is, the systems are single-
input systems. So, by Eq. (32) and Eq. (33), we know, for any state $x_{0}\in
R^{(1)}(N)$, there must exist two finite positive number $k_{1}$ and
$k_{2}(k_{2}<k_{1}\leq N)$ satisfied one of the following conditions

$\displaystyle(a1)\;$ $\displaystyle x_{0}\in\partial
R^{(1)}\left(k\right)\cap\partial R^{(2)}\left(k\right),\;\;k=1,k_{1}$ (36)
$\displaystyle(a2)\;$ $\displaystyle x_{0}\in\partial
R^{(1)}\left(k\right)\cap\widetilde{R}^{(2)}\left(k\right),\;\;k=1,k_{1}$ (37)
$\displaystyle(a3)\;$ $\displaystyle
x_{0}\in\widetilde{R}^{(1)}\left(k\right)\cap\widetilde{R}^{(2)}\left(k\right),\;\;k=1,k_{1}$
(38) $\displaystyle(b1)\;$ $\displaystyle x_{0}\in\partial
R^{(1)}\left(k_{1}\right)\cap\partial R^{(2)}\left(k_{2}\right)$ (39)
$\displaystyle(b2)\;$ $\displaystyle x_{0}\in\partial
R^{(1)}\left(k_{1}\right)\cap\widetilde{R}^{(2)}\left(k_{2}\right)$ (40)
$\displaystyle(b3)\;$ $\displaystyle
x_{0}\in\widetilde{R}^{(1)}\left(k_{1}\right)\cap\widetilde{R}^{(2)}\left(k_{2}\right)$
(41)

where $\widetilde{R}(k)=\left(R(k)\setminus\partial R(k)\right)\setminus
R(k-1)$. For controlling the state $x_{0}$ to the origin, the input sequence
$u^{(i)}_{0,N-1}(x_{0})$ must satisfies the following state eauation.

$\displaystyle x_{0}=\left[A^{-1}B,A^{-2}B,\dots,A^{-N}B\right]\times
u^{(i)}_{0,N-1}(x_{0})$ (42)

Then, corresponding to the above 4 conditions, the dismension of the solution
space $U^{(i)}_{N}(x_{0})$ of the Eq. (42) are as follows

$\displaystyle(a1)\;$ $\displaystyle\dim U^{(1)}_{N}(x_{0})=\dim
U^{(2)}_{N}(x_{0})=N-k,\;\;k=1,k_{1}$ (43) $\displaystyle(a2)\;$
$\displaystyle\dim U^{(1)}_{N}(x_{0})=N-k<N-k+1=\dim
U^{(2)}_{N}(x_{0}),\;\;k=1,k_{1}$ (44) $\displaystyle(a3)\;$
$\displaystyle\dim U^{(1)}_{N}(x_{0})=\dim
U^{(2)}_{N}(x_{0})=N-k+1,\;\;k=1,k_{1}$ (45) $\displaystyle(b1)\;$
$\displaystyle\dim U^{(1)}_{N}(x_{0})=N-k_{1}<N-k_{2}=\dim U^{(2)}_{N}(x_{0})$
(46) $\displaystyle(b2)\;$ $\displaystyle\dim
U^{(1)}_{N}(x_{0})=N-k_{1}<N-k_{2}+1=\dim U^{(2)}_{N}(x_{0})$ (47)
$\displaystyle(b3)\;$ $\displaystyle\dim
U^{(1)}_{N}(x_{0})=N-k_{1}+1<N-k_{2}+1=\dim U^{(2)}_{N}(x_{0})$ (48)

Furthermore, if we have

$\displaystyle R^{(1)}(i)\subset R^{(2)}(i),\;\forall i\leq N,$ (49)

then the given state $x_{0}$ and the corrsponding solution space
$U^{(i)}_{N}(x_{0})$ are satisfied only cases a2), a3), b2), and b3) in above
6 cases. Hence, whether the two controllability regions satisfy Eq. (32) or
(49), we have

$\displaystyle\dim U^{(1)}_{N}(x_{0})\leq\dim U^{(2)}_{N}(x_{0})$ (50)

So, considered that the higher the space dimension is and the more the number
of the states in the state space is, for any state $x_{0}\in R^{(2)}(N)$, the
solution space of the system $\Sigma_{2}$ is larger than that of the system
$\Sigma_{1}$, and then the systems $\Sigma_{2}$ for controlling the state to
$x_{0}$ to the origin will be with more control strategies than the system
$\Sigma_{1}$ .

By Theorem 1 , we have the following discussions:

(1) Not only the time waste can be reduced by promoting the control ability,
but also other closed-loop performance related the control time waste can be
improved.

(2) In fact, that the solution space of the input variables for the control
problems is bigger implies that the control strategies in the solution space
are with better robustness, and then the closed-loop control systems is also
with better robustness.

Therefore, optimizing the open-loop control ability are with very greater
signification for these practical control engineering problems and it’s very
necessary to optimize the control ability. To optimize the control ability, it
is necessary to establish the quantify analysis and computing method for the
control ability. Paper [17] prove an analytical computing equation for the
volume of the controllability region and deconstruct the volume equation to
construct some analytical factors about the shape of the controllability
region. Based on these analytical expressions of the volume and shape factors,
the optimizing and promoting methods for the control ability can be set up
conveniently.

The analytic expressions of the volume and shape factors of the
controllability region, which can be regard as a special zonotope generated by
the matrix pair, is got in paper [17] and [16] . Based on the analytic
computation of the volume and shape factors, comparing the size of the
controllability regions of LDT systems is become possible, and then by Theorem
1, we can compare the control ability between the difference LDT systems.
Furthmore, according the control ability computing, we can choose the
controlled plant for constructing engineering equipment systems, determine the
input variables for the feedback control systems, place the location of the
actuator for the lager mechanical systems, etc.

##  6 Numerical Experiments

###### Example 1

Considered the following LDT models $\Sigma_{d}\left(A_{d},B_{d}\right)$ and
$\Sigma_{a}\left(A_{a},B_{a}\right)$ for DC motor with the excitation
controller and AC motor with the variable frequency controller, respectively

$\displaystyle\;x_{d}(k+1)=\left[\begin{array}[]{ccc}0&1&0\\\ 0&0&1\\\
0.69527&-2.3565&2.660\end{array}\right]x_{d}(k)+\left[\begin{array}[]{c}0\\\
0\\\ 8.74\end{array}\right]u_{d}(k)$ (57)
$\displaystyle\;x_{a}(k+1)=\left[\begin{array}[]{ccc}0&1&0\\\ 0&0&1\\\
0.65711&-2.2691&2.610\end{array}\right]x_{a}(k)+\left[\begin{array}[]{c}0\\\
0\\\ 19.17\end{array}\right]u_{a}(k)$ (64)

where the input variable $u_{d}$ and $u_{a}$ are the input voltages, and the
state variable $x_{d}$ and $x_{a}$ are consist of the main circuit current,
the speed and acceleration of two motors, respectively. The rated values of
the input variable and state variables are respectively as

$\displaystyle\left(u_{d}^{*},i_{d}^{*},y_{d}^{*},\dot{y}_{d}^{*}\right)=(\textnormal{24V,
30A, 200rad/s, 30rad/s}^{2})$
$\displaystyle\left(u_{a}^{*},i_{a}^{*},y_{a}^{*},\dot{y}_{a}^{*}\right)=(\textnormal{12V,
30A, 230rad/s, 35rad/s}^{2})$

, these state variables are expected in operation intervals with the upper
bounds  {30A, 180rad/s, 30rad/s2 }.

The problem here is which motor is with the stronger control ability in the
rater interval and expecting interval, respectively.

The computing and analyzing process are introducted as follows.

(1) By Eqs. (8) and (9), for comparing the control ability of the two motors
in its variable rated intervals, the system models
$\Sigma\left(A_{d},B_{d}\right)$ and $\Sigma\left(A_{a},B_{a}\right)$ are
transformed respectively as

$\displaystyle\left(A_{d},b_{d}\right)=\left(\left[\begin{array}[]{ccc}0&6.6667&0\\\
0&0&0.1500\\\
0.6953&-15.7100&2.6600\end{array}\right],\;\left[\begin{array}[]{c}0\\\ 0\\\
6.9920\end{array}\right]\right)$ (71)
$\displaystyle\left(A_{a},b_{a}\right)=\left(\left[\begin{array}[]{ccc}0&7.6667&0\\\
0&0&0.1522\\\
0.5632&-14.9112&2.6100\end{array}\right],\;\left[\begin{array}[]{c}0\\\ 0\\\
6.5726\end{array}\right]\right)$ (78)

The computing results for the volumes, the shape factors
$\left\\{f_{1},f_{1,1,2},f_{1,1,3},f_{1,2,3}\right\\}$, and the side lengths
$\left\\{f_{2,1,2},f_{2,1,3},f_{2,2,3}\right\\}$ of the circumscribed
hypercube (or circumscribed rhomboid) of the controllability regions [16] are
shown in Table 1, and Fig. 2 illustrate the 3-D controllability regions by the
3 2-D projection drawing in $x_{1}-x_{2},\;x_{1}-x_{3}$, and $x_{2}-x_{3}$
planes. By the figures, we can see, the controllability region of the AC motor
is more flatted than that of the DC motor, and accordingly its shape factor
$f_{1}$ is less than the DC motor.

By paper [16], the size of the controllability regions are depend on its
volume and shape described by the shape factors and the side lengths. When the
side lengths are approximated, that is, the circumscribed rhomboids of the
controllability regions are approximated, the greater the value of the factor
$f_{1}$ is, the bigger the volume of the region is, and then the bigger the
region is. When the value of the factor $f_{1}$ are approximated, the greater
the side lengths are, and then the bigger the region is. By Table 1 and Fig.
2, the controllability region of the DC motor is bigger than the AC motor in
the rated intervals, and then, based on Definitions 1 and 2, the controll
ability of the DC motor in the rated intervals is stronger than the AC motor.
Therefore, by Theorem 1 , the excitation controller for the DC motor is with
the bigger parameter space designing the controller or the control law, and
then the controller with the better closed-loop time-attribute performance
index and robustness can be gotten than the variable frequency controller for
the AC motor.

(a) DC motor in the rated intervals with the 2-D shape factors {0.1920,
0.4134, 0.2405 }

(b) AC motor in the rated intervals with the 2-D shape factors {0.1474,
0.3262, 0.1878 }

Figure 2: The 3-D controllability region with the 2-D shape factors $\left\\{f_{1,1,2},f_{1,1,3},f_{1,2,3}\right\\}$ illustrated by 3 2-D projection drawing  Table 1: Numerical results for the reachable regions | rated interval | expectivng interval
---|---|---
factors | DC | AC | DC | AC
volume | 3.5038e7 | 1.4307e7 | 3.8931e7 | 2.1328e7
$f_{1}$ | 0.0191 | 0.0090 | 0.0191 | 0.0090
$f_{1,1,2}$ | 0.1920 | 0.1474 | 0.1920 | 0.1474
$f_{1,1,3}$ | 0.4134 | 0.3262 | 0.4134 | 0.3262
$f_{1,2,3}$ | 0.2405 | 0.1878 | 0.2405 | 0.1878
$f_{2,1}$ | 1.2330e4 | 1.6035e4 | 1.2345e4 | 1.6801e4
$f_{2,2}$ | 4.0026e4 | 4.4408e4 | 4.0077e4 | 4.6827e4
$f_{2,3}$ | 3.5779e4 | 3.3471e4 | 3.5825e4 | 3.5511e4

(2) By Eqs. (13) and (14), for comparing the control ability of the two motors
in the expecting intervals for these state variables, the system models
$\Sigma\left(A_{d},B_{d}\right)$ and $\Sigma\left(A_{a},B_{a}\right)$ are
transformed respectively as

$\displaystyle\left(A_{d},b_{d}\right)=\left(\left[\begin{array}[]{ccc}0&6.0000&0\\\
0&0&0.1667\\\
0.6953&-14.1390&2.6600\end{array}\right],\;\left[\begin{array}[]{c}0\\\ 0\\\
6.9920\end{array}\right]\right)$ (85)
$\displaystyle\left(A_{a},b_{a}\right)=\left(\left[\begin{array}[]{ccc}0&6.0000&0\\\
0&0&0.1667\\\
0.6571&-13.6146&2.6100\end{array}\right],\;\left[\begin{array}[]{c}0\\\ 0\\\
7.6680\end{array}\right]\right)$ (92)

The computing results are shown in Table 1, and the 3-D controllability
regions are illustrated by the 3 2-D projection drawing in Fig. 3. By the
figures, we can see, the controllability region of the AC motor is more
flatted than that of the DC motor, and accordingly its shape factor $f_{1}$ is
less than the DC motor.

From Table 1 and Fig. 3, we can see, the controllability region of the DC
motor is bigger than the AC motor in the expecting variable intervals, and
then, based on Definitions 1 and 2, the controll ability of the DC motor in
the rated intervals is stronger than the AC motor. Therefor, by Theorem 1 ,
the better controller for the DC motor can be designed than the AC motor.

(a) DC motor in the expecting interval

(b) AC motor in the expecting interval

Figure 3: The 3-D controllability region illustrated by 3 2-D projection
drawing

##  7 Conclusions

In this article, the definition on the time-attribute control ability, and the
relation between the open-loop control ability and the closed-loop performance
are studied systematically. Firstly, to define and compare the state control
ability, the normalization of the input variables and state variables in the
different control plants or one controlled plant with the different system
parameters are discussed. With the help of the normalization, the time-
attribute control ability with the unit input constraint (input amplitude
limited) can be defined. Finally, a theorem on the relations among the open-
loop control ability, the control strategy space (i.e., the solution space of
the input variables for control problems), and the closed-loop time
performance is purposed and proven. Therefore, it is necessary to optimize the
control ability for the practical engineering problems. Based on the results
in paper [17], the optimizing and promoting methods for the control ability
can be set up conveniently, and then the controller with the greater designing
parameter space and then the better closed-loop peroformance index and
robustens can be got.

## References

  * Bernstein and Michel [1995] D. Bernstein, A. Michel, A chronological bibliography on saturating actuators, Inter. J. of Robust and Nonlinear Control 5 (1995) 375–380.
  * Canfield and Nkhumise [2017] S.L. Canfield, R. Nkhumise, Controllability ellipse to evaluate performance of mobile manipulators for manufacturing tasks, Journal of Mechanisms and Robotics 9 (2017).
  * Chen [1998] C.T. Chen, Linear system theory and design, Oxford University Press, Inc. New York, NY, USA, 3rd edition, 1998.
  * Dullerud and Paganini [2000] G.E. Dullerud, F. Paganini, A Course in Robust Control Theory: A Convex Approach, Sringer, 2000.
  * Georges [1995] D. Georges, The use of observability and controllability gramians or functions for optimal sensor and actuator location in finite-dimensional systems, in: Proc. of IEEE Conf. on Decision and Control, New Orleans, LA, USA, p. 3319–3324.
  * Hu and Lin [2001] T. Hu, Z. Lin, Control systems with actuator saturation: analysis and design, BirkhTauser, Boston, 2001\.
  * Hu et al. [2002] T. Hu, Z. Lin, L. Qiu., An explicit description of the null controllable regions of linear systems with saturating actuators, Systems & Control Letters 47 (2002) 65–78.
  * Ilkturk [2015] U. Ilkturk, Observability Methods in Sensor Scheduling, Ph.D. thesis, ARIZONA STATE UNIVERSITY, 2015.
  * Kailath [1980] T. Kailath, Linear systems, Prentice-Hall, Englewood Cliffs, NJ, 1980\.
  * Kalman et al. [1963] R.E. Kalman, Y.C. Ho, K.S. Narendra, Controllability of dynamical systems, Contributions to Differential Equations 1 (1963) 189–213.
  * Kurzhanskiy and Varaiya [2007] A. Kurzhanskiy, P. Varaiya, Ellipsoidal techniques for reachability analysis of discrete-time linear systems, IEEE Trans. on Automatic Control 52 (2007) 26–38.
  * Nkhumise [2016] R.M. Nkhumise, Controllability Ellipse – a Method to Eavluate Performance of Mobile Manipulators Applied to Welding, Master’s thesis, Tennessee Technological University, 2016.
  * Pasqualetti et al. [2014] F. Pasqualetti, S. Zampieri, F. Bullo, Controllability metrics, limitations and algorithms for complex networks, IEEE Trans. on Control of Network Systems 1 (2014) 40–52.
  * Polyak et al. [2008] B. Polyak, S. Nazin, M. Khlebnikov, The invariant ellipsoid technique for analysis and design of linear control systems, in: Advances in Mechanics: Dynamics and Control: Proceedings of the 14th International Workshop on Dynamics and Control, ed. F.L. Chernousko, G.V. Kostin, V.V. Saurin, Moscow: Nauka,, pp. 239–246.
  * VanderVelde and Carignan [1982] W. VanderVelde, C. Carignan, A dynamic measure of controllability and observability for the placement of actuators and sensors on large space structures, Technical Report, NASA-CR-168520, SSL-2-82, 1982\.
  * Zhao [2020a] M.W. Zhao, Analytical factors for describing the control ability of linear discrete-time systems, arXiv:2004.07982 (2020a).
  * Zhao [2020b] M.W. Zhao, Exact volume of zonotopes generated by a matrix pair, arXiv:2004.05530 (2020b) 20.


# Contrasting Third-Party
Package Management User Experience

Syful Islam, Raula Gaikovina Kula, Christoph Treude†, Bodin Chinthanet,
Takashi Ishio, Kenichi Matsumoto  Nara Institute of Science and Technology
(NAIST), Japan
†University of Adelaide, Australia
Email: {islam.syful.il4, raula-k, bodin.chinthanet.ay1, ishio,
<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

The management of third-party package dependencies is crucial to most
technology stacks, with package managers acting as brokers to ensure that a
verified package is correctly installed, configured, or removed from an
application. Diversity in technology stacks has led to dozens of package
ecosystems with their own management features. While recent studies have shown
that developers struggle to migrate their dependencies, the common assumption
is that package ecosystems are used without any issue. In this study, we
explore 13 package ecosystems to understand whether their features correlate
with the experience of their users. By studying experience through the
questions that developers ask on the question-and-answer site Stack Overflow,
we find that developer questions are grouped into three themes (i.e., Package
management, Input-Output, and Package Usage). Our preliminary analysis
indicates that specific features are correlated with the user experience. Our
work lays out future directions to investigate the trade-offs involved in
designing the ideal package ecosystem.

##  I Introduction

Package management is crucial to most technology stacks in software
development, especially when developers are building web or mobile
applications. Package managers serve more than five million open source
packages that developers can easily adopt to introduce new functionality into
their projects, without the need to create these functions from
scratch111According to www.libraries.io.. In 2020, GitHub showed its
investment in package support when it acquired the Node.js package ecosystem
(i.e., npm), which serves over 1.3 million packages to roughly 12 million
developers, and is constantly growing each day [1].

Package management is an automated solution for applications that heavily rely
on package dependencies. They solve the ‘dependency hell’222A term made
popular by this blog
https://web.archive.org/web/20150708101023/http://archive09.linux.com/feature/155922
dilemma, which is a colloquial term used to describe the frustration of users
when an application has dependencies that do not run with other versions of
dependencies (i.e., incompatibility). As the number of dependencies grows
(i.e., forming a large tree of interdependent packages) within the
application, so do the chances of incompatibility between dependencies. To
address such problems, the package managers act as intermediary brokers
between an application and a package dependency to ensure that a verified
package is correctly installed, configured, or removed from an application.

Diversity in technology stacks and programming languages has led to a variety
of managers that cover different package ecosystems. For instance, npm brokers
packages that run in the Node.js environment and are written in JavaScript,
while the PyPI package ecosystem is built specifically to handle Python
package dependencies. Although recent studies have investigated dependency
management from the perspectives of updates (i.e., update an existing
dependency to a more recent version) and migration (i.e., replace, remove, or
add a new dependency) [2, 3, 4, 5, 6], the focus has not been on the package
manager itself. For example, Bogart et al. [3] cite reasons why developers do
not update, including ecosystem community values such as policies, supporting
infrastructure, and accepted trade-offs to negotiate dependency changes. Other
work [4] found that 69% of the developers claimed to be unaware of the need to
update and were not likely to prioritize a library update, as it was perceived
to be extra workload and responsibility. Bogart et al. [7] argued that
awareness mechanisms based on various notions of stability can enable
developers to make migration decisions. While these studies have shown that
developers struggle to migrate their dependent packages, the common assumption
is that the management systems all work in the same manner.

TABLE I: Summary of each package ecosystem and their features.

| Package
---
Ecosystem
| Programming
---
Language
Tiobe Rank | Environment |  | Dependency
---
Tree
| Package
---
Archive link
| # of packages
---
in ecosystem
PyPI | Python | 2 | Python | Flat | pypi.org | 372,334
Maven | Java | 3 | JVM | Flat | Maven.org | 417,669
Bower | JavaScript | 7 | Node.js | Flat | bower.io | 69,625
Meteor | JavaScript | 7 | Node.js | Nested | atmospherejs.com | 13,410
npm | JavaScript | 7 | Node.js | Nested (v2) | npmjs.com | 1,866,208
Packagist | PHP | 8 | PHP | Flat | packagist.org | 316,855
Puppet | Ruby | 13 | Ruby MRI | Flat | forge.puppet.com | 6,923
RubyGems | Ruby | 13 | Ruby MRI | Flat | rubygems.org | 173,603
CRAN | R | 14 | RStudio | Flat | cran.r-project.org | 20,324
CPAN | Perl | 15 | Perl | Flat | metacpan.org | 38,459
GO | Golang | 20 | Go | Flat | pkg.go.dev | 390,438
NuGet | C#, VB | 5, 6 | .NET | Flat | nuget.org | 264,221
Anaconda | Python, R, C# | 2, 14, 5 | Anaconda | Flat | anaconda.org | 12,763

TABLE II: Topics extracted from Stack Overflow questions. The ten topics are
categorized into three themes.

Theme | Topic Id | Topic Name | Sample Keywords
---|---|---|---
| 0, 1 | Dependency (2) | dependency, version, specific, release, artifact, resolve, late, update, change, repository
| 6, 8 | Build (2) | build, project, create, generate, make, jar, war, compile, failure, resource
Package Management | 3, 11 | Configuration (2) | package, add, reference, install, set, environment, variable, import, module, library
| 7 | Testing | run, test, command, fail, execute, integration, unit, report, clean, surefire
| 9, 14 | Error (2) | error, throw, give, exception, load, unable, fix, issue, work, problem
| 10 | Services | application, deploy, web, spring, app, tomcat, deployment, service, engine, boot
Input-Output | 5 | Server-client | server, client, user, request, http, connection, access, response, message, proxy
| 2 | Interface | file, time, read, write, image, output, channel, log, process, multiple
Package | 13 | Package function | type, function, struct, string, variable, interface, slice, method, argument, pass
4, 12 | Package usage (2) | template, react, collection, event, render, helper, database, component, field, document

(a) Package ecosystem vs. topic, where users of different package ecosystems
ask different questions. (b) Package ecosystem vs. topic themes, where most
users of a package ecosystem ask questions on package management.

Figure 1: Heatmaps that show package ecosystem and extracted topics (a) and
themes (b). Users of different package ecosystems ask different kinds of
questions.

The purpose of this paper is to present initial results and a research agenda
on how packages are managed within different package ecosystems, and how this
impacts the experience of software developers using a package ecosystem. We
report the results of a preliminary study to analyze developer questions from
the commonly used question-and-answer site Stack Overflow. By mining 497,249
Stack Overflow posts related to 13 different package ecosystems for the 20 top
programming languages, we study the topics and difficulties faced by
developers.

Our preliminary results show that usage issues can be categorized into ten
topics belonging to three themes (i.e., management, input-output, and usage).
Importantly, the results show that the user experience is different, depending
on the package ecosystem. Combining the results, we speculate that users from
the Go and Meteor package ecosystems have an easier time finding answers to
their questions on Stack Overflow compared to users of other package
ecosystems.

The next logical step in our research agenda is a further exploration of the
underlying causes and benefits of using each package ecosystem. Our vision is
that a series of studies to investigate the benefits and drawbacks from
different package ecosystems will help piece together what an ideal package
manager and package ecosystem should look like.

##  II Package Ecosystems and their features

To explore the most popular software ecosystems, we start from the top twenty
programming languages from tiobe.com333Details of the dataset are available at
https://www.tiobe.com/tiobe-index/ as of June, 2021. To extract the package
ecosystems for each language, we use libraries.io444https://libraries.io/ to
gather the package ecosystems that are related to these programming languages.
Note that some of the package ecosystems do not have a dedicated package
manager, and that there can be several package ecosystems that are written in
one programming language. Other features include the dependency tree555An
example of differences in dependency trees is described at
https://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html and
environment.

Table I shows a summary of features that are specific to each of our package
ecosystems. In detail, we find that nine of our package ecosystems support a
specific programming language (i.e., Maven for Java, npm and Bower for
JavaScript, Go for GoLang, RubyGems for Ruby, PyPI for Python, CPAN for perl,
CRAN for R, Packagist for PHP). The other package ecosystems support multiple
programming languages. As shown, a package ecosystem serves from 6,900 to over
1.8 million packages.

Figure 2: Language feature heatmap shows that different package ecosystems in
different languages provide different user experiences.

Figure 3: Environment feature heatmap shows that different package ecosystems
in different environments provide different user experiences.

Figure 4: Dependency tree feature heatmap shows that dependency tree
correlates with user experiences (i.e., package ecosystems with a nested
dependency face package usage issues, while flat dependency trees face
questions related to dependencies)

##  III Mining User Experience from SO

To understand the user experience related to different package ecosystems, we
mined developer questions about the package ecosystems from Stack Overflow,

###  III-A Mining Stack Overflow for package manager experience

We use the SOTorrent dataset [8] as of December 2019. We followed three steps.
In the first step, we used the #package-managers tag to extract 806 questions.
Second, to discover other relevant tags, we used a semi-automated method to
check tags that co-occurred with #package-managers (i.e., 626 tags). Three of
the authors manually checked each of the 626 tags to determine a list of 28
tags relevant to each package ecosystem. In the final step, we extracted posts
that were tagged with at least one of these 28 relevant tags. In the end, we
collected 497,249 Stack Overflow posts, with 214,609 questions and 282,640
answers. All data and scripts are made available through our replication
package666Details of the data and scripts:
https://doi.org/10.5281/zenodo.5187873.

###  III-B Question Topic Modeling

To explore topics in our dataset, we applied the popular Latent Dirichlet
allocation (LDA) topic modeling technique, which is also used in related work
(e.g., [9, 10, 11]). To prepare our dataset, we first filter out irrelevant
information from question titles, namely emails, newline characters, and stop
words. We then build a bigram model using Gensim777Gensim model:
https://radimrehurek.com/gensim/ and lemmatize the words. Next we use the LDA
Mallet (version 2.0.8) model to obtain topics. We experimented with different
topic numbers ($k$) based on coherence score, with $k=15$ giving the best
score.

We manually inspected and labelled each topic, resulting in the merge of some
of the 15 topics for a total of 10 topics. We also identified three higher-
level themes. Table II shows the three themes and the 10 topics modeled from
the user experience. The first theme is related to package management, which
includes keywords such as dependencies, builds, configurations and so on. The
second theme is related to input and output for packages. This theme includes
keywords such as services, server-client and interfaces. The final theme is
about the low-level topics of package function and package usage.

##  IV Preliminary Results

We contrast developer topic discussions relating to different ecosystems from
the two perspectives of (a) package management features, and (b) question
popularity and difficulty.

TABLE III: Summary of popularity and difficulty of topics.

|  | Popularity | Difficulty
---|---|---|---
Theme | Topic | # Questions |  | #Score
---
(median)
| #Views
---
(median)
| Questions with accepted
---
answer (%)
| PD Score
---
(%)
| Dependency | 40,519 | 1 | 420 | 48 | 0.24
| Build | 27,191 | 1 | 409 | 46 | 0.24
Package Management | Configuration | 26,748 | 1 | 348 | 45 | 0.29
| Error | 25,731 | 1 | 447 | 44 | 0.22
| Testing | 14,194 | 1 | 440.5 | 45 | 0.23
| Server-Client | 13,770 | 1 | 319 | 48 | 0.31
Input-Output | Interface | 12,582 | 1 | 277 | 53 | 0.36
| Services | 13,256 | 0 | 405 | 43 | 0.25
Package | Package usage | 26,226 | 0 | 216 | 53 | 0.46
Package function | 14,392 | 1 | 284 | 64 | 0.35
Total |  | 214,609 |  |  |  |

###  IV-A Contrasts in Features: Topics and Features

We use heatmap visualizations to contrast differences between the features of
a package ecosystem and the kinds of topics that users ask about on Stack
Overflow. The heatmap uses greyscale colored cells to show a two-dimensional
matrix between the topics and the features of the package ecosystem. We report
the frequency counts of each dimension that is reflected in the cells.

Figure 1 shows that the topics related to each package ecosystem differ. For
example, package ecosystems like CRAN, CPAN, and Conda tend to attract
configuration related questions, while Go and Meteor have their users ask
questions related to the package function and usage. Under the broader themes,
the results are consistent with the results of Table II, as most topics are
related to package management. This evidence suggests that users of Go and
Meteor package ecosystems may face different types of issues when compared to
users of other package ecosystems.

Takeaway 1: Users from different package ecosystems report different issues.
Findings indicate that RubyGem users report errors, while NuGet users report
configuration issues.

Taking a deeper look at the features, we can see that users of package
ecosystems built for JavaScript technologies and environments tend to
encounter different types of issues, whereas users of package ecosystems built
for the Python, R and Perl languages and related environments tend to focus on
configuration issues (cf. Figure 2 and Figure 3). In terms of the dependency
tree, Figure 4 shows that flat dependencies tend to attract dependency related
issues, while users of package ecosystems with nested dependency trees
encounter package usage related issues. One possible explanation is that
nested dependencies are a solution to ‘dependency hell’, thus removing
dependency related issues for package ecosystems with nested dependency
trees888This issue is discussed by this npm blog post at
https://npm.github.io/how-npm-works-docs/theory-and-design/dependency-
hell.html.

Takeaway 2: Users from different programming languages report different kinds
of issues. We find that users of applications that are developed using the
Python language reported more configuration issues, when compared to Ruby
users who report errors.

###  IV-B Contrasts in Responses: Popularity and Difficulty

To characterize package ecosystem topics in terms of their popularity and
difficulty, we measure both metrics as defined by Yang et al. [10]. We
calculate the PD (post difficulty) score as $\frac{AnswerCount\
(median)}{ViewCount\ (median)}$ for each post, i.e., the smaller the PD score,
the more difficult it is to answer a question. We then summarize the median PD
(i.e., $PD(median)$) for each topic and the median value for the popularity
(i.e., $Popularity(median)$).

Table III shows that errors and testing are the most difficult topics to
provide answers for. In contrast, questions that relate to package usage and
package function are the easiest for users to get an answer. Combining these
results with the relationships between themes and package ecosystems (cf.
Figure 1), we speculate that users of the Go and Meteor package ecosystems may
have a relatively easy experience in finding answers to their questions on
Stack Overflow.

Takeaway 3: Different topics imply different degrees of difficulty. Errors and
testing are the most difficult, while package usage is the easiest to answer.
Combining with Takeaway 1, users of the Go and Meteor package ecosystems face
a relatively easy experience.

##  V Limitations

The first threat to internal validity is related to our collected data. We
acknowledge that some posts may be mislabelled (i.e., missing tags or
incorrect tags) on Stack Overflow. The second threat is related to the
correctness of techniques used in this study, such as choosing the appropriate
number of topics (k=15) for the LDA model. A different number might have led
to different results. Manually labeling the topics based on keywords
introduced another threat to the validity. We mitigated this threat by
involving multiple authors in the labelling process.

##  VI Implications

We now discuss implications of our work applicable to developers and package
manager designers:

#### Developers

Developers should be conscious that their choice of a package ecosystem will
impact their user experience – not all package ecosystems are the same as
design choices such as hierarchy structure and language support are correlated
with what questions developers are likely to encounter. When starting a new
project, developers might be able to choose an ecosystem based on our
insights. In other cases it might be too late to switch ecosystems, but users
might still be able to consider the benefits of (somewhat) compatible package
ecosystems, such as npm and Meteor. Furthermore, as applications such as
mobile apps require support for multiple technology stacks, developers should
be aware of the trade-offs when switching technologies, i.e., when porting a
Java application (Maven) to the web as a JavaScript application (npm).
Developers can use our findings to better understand what technical background
knowledge they should have regarding package ecosystems.

#### Package manager designers

Designers need to be aware of the impact of package ecosystem design features
on the problems that developers may encounter as some design choices are
correlated with more questions on certain topics raised on Stack Overflow.
Designers should be proactive about issues frequently encountered by package
ecosystem users, by providing thorough documentation and/or improving package
ecosystems where possible. Designers should also make it easy for developers
to find the information they need to resolve issues, e.g., by providing good
error messages, while other package ecosystems may require better
documentation for package manager configuration.

##  VII Roadmap

In this preliminary study, we explore thirteen package ecosystems to
understand whether their differences in terms of features correlate with user
experience. We find that developers ask package ecosystem related questions
that can be clustered into ten different topics, which can be grouped into
three themes, and that different topics are prevalent for different
ecosystems.

The next logical step is further exploration into the underlying causes and
benefits when using each package ecosystem. A thorough study to investigate
the trade-offs between benefits and drawbacks of each package ecosystem will
help piece together what the ideal package ecosystem should look like.
Researchers could use our findings to prioritise research efforts, as our work
is the first to acknowledge that developers encounter issues when using
package ecosystems.

Future work is needed in particular in teasing apart the effects of different
features of package ecosystems and their interplay. While some features of a
package ecosystem are a given (e.g., the programming language), others provide
more freedom to designers (e.g., dependency trees). In addition, interviewing,
observing, and/or surveying software developers would further allow for
triangulation of our preliminary findings to understand the impact of
ecosystem features on developers’ decision processes.

Acknowledgments. This work is supported by Japanese Society for the Promotion
of Science (JSPS) KAKENHI Grant Numbers JP18H04094, JP20K19774, and
JP20H05706.

## References

  * [1] the npm blog, “npm blog: Next Phase Montage,” https://blog.npmjs.org/post/612764866888007680/next-phase-montage, 2020, (Accessed on05/20/2020).
  * [2] J. Cox, E. Bouwers, M. Eekelen, and J. Visser, “Measuring dependency freshness in software systems,” in2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (ICSE), 2015, pp. 109–118.
  * [3] C. Bogart, C. Kastner, J. Herbsleb, and F. Thung, “How to break an api: cost negotiation and community values in three software ecosystems,” in Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2016, pp. 109–120.
  * [4] R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies?” Empirical Software Engineering,vol. 23, no. 1, pp. 384–417, 2018.
  * [5] A. Decan, T. Mens, and E. Constantinou, “On the impact of security vulnerabilities in the npm package dependency network,” in Proceedings of the 15th International Conference on Mining Software Repositories,2018, pp. 181–191.
  * [6] A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019.
  * [7] C. Bogart, C. Kastner, and J. Herbsleb, “When it breaks, it breaks: How ecosystem developers reason about the stability of dependencies,” in Proceedings of the 2015 30th IEEE/ACM International Conference on Automated Software Engineering Workshop (ASEW), ser. ASEW ’15.USA: IEEE Computer Society, 2015, p. 86–89.
  * [8] S. Baltes, L. Dumani, C. Treude, and S. Diehl, “Sotorrent: reconstructing and analyzing the evolution of stack overflow posts,” in Proceedings of the 15th International Conference on Mining Software Repositories, MSR 2018, Gothenburg, Sweden, May 28-29, 2018, A. Zaidman,Y. Kamei, and E. Hill, Eds. ACM, 2018, pp. 319–330.
  * [9] C. Rosen and E. Shihab, “What are mobile developers asking about? a large scale study using stack overflow,” Empirical Software Engineering,vol. 21, no. 3, pp. 1192–1223, 2016.
  * [10] X.-L. Yang, D. Lo, X. Xia, Z.-Y. Wan, and J.-L. Sun, “What security questions do developers ask? a large-scale study of stack overflow posts,” Journal of Computer Science and Technology, vol. 31, no. 5, pp. 910–924, 2016.
  * [11] M. Ahasanuzzaman, M. Asaduzzaman, C. K. Roy, and K. A. Schneider,“Classifying stack overflow posts on api issues,” in2018 IEEE 25th international conference on software analysis, evolution and reengineering (SANER). IEEE, 2018, pp. 244–254.