Top-down Paradigm in Engineering Software Integration

ar
X
iv
:0
90
8.
08
33
v1
[
cs
.C
E]
6
A
ug
20
09
Top-down Paradigm in Engineering Software
Integration
August 6, 2009
Petr R. Ivankov*
e-mail: * monstr3d@korolev-net.ru
Abstract
The top-down approach of engineering software integration is consid-
ered in this parer. A set of advantages of this approach are presented, by
examples. All examples are supplied by open source code.
1 Introduction
Historically engineering software integration is rather chaotic then planned. Dif-
ferent CAD products had been integrated with CAE and CAM products, Mat-
lab had been integrated with Simulink etc. This integration history could be
schematically presented in figure 1.
However chaotic way is not optimal way. For example C++ programming lan-
guage had been designed chaotically. Languages of next generation (Java, C#)
had been designed by planned way. C++ does not support automatic garbage
collection. But any present day project should have it. So big C++ projects
contain smart pointers those provide automatic garbage collection. Since smart
pointer is not intrinsic C++ feature there exists a lot of versions of smart point-
ers. Integration of set of projets with different versions of smart pointers has a
set of disadvantages. In this case integrated product is not clear, volume of its
code is overloaded etc. Present day programming languages (Java, C#) sup-
port Reflection but C++ does not support it. However Reflection is very useful
1

Figure 1: Chaotic integration of software products
feature for any big project. So big C++ projects have different versions of Re-
flection emulation. Comparting of intrinsic reflection and reflection emulation
is presented in figure 2.
Figure 2: Reflection emulation and intrinsic reflection
In case of emulation we have additional code without essentially new function-
ality. If we would like integrate a set of projects by such way then we will
obtain a lot of lumber. Such disadvantage have any chaotic way of integration.
But chaotic way has top-down design alternative. The top-down paradigm is
presented in figure 3.
Let us explain meaning of figure 3. First of all we have pure abstract library
devoted to science and engineering. This library is used by derived libraries
devoted to different brunches of science and engineering. Libraries can be ab-
stract. Integration can use other engineering software as third party. Libraries
are being used by integrated products. Green, pig and purple color are used for
libraries, third party and integrated products respectively. Italic font is used for
abstract libraries.
2

Figure 3: Top-down integration of engineering software products
2 Interoperability issues
Chaotic way interoperability disadvantage is well known. Chaotic way of inter-
operability of N products requires development of N(N−1)2 adapters. Adapters
provide interoperability between objects of any pair of N element set. In figure
4 (a) we have 8 products. Two sided arrows are adapters. If we use top-down
Figure 4: Interoperability
scheme then we should develop adapters between base object and other objects.
So we should have N adapters only. The base object is 0 - object in figure 4
(b).
3

3 Category theory as prototype
Pure abstract library for science and engineering should have very high level of
abstraction. However this level of of abstraction is already developed in math.
In mathematics, category theory deals in an abstract way with mathematical
structures and relationships between them: it abstracts from sets and functions
to objects linked in diagrams by morphisms or arrows. High level of abstraction
of Category Theory is explained in [1]. This book contains figure 5 with following
text.
Figure 5: Object and arrow
We did not actually say what a and f are. The point is that they can be anything you like. a
might be a set with f its identity function. But f might be a number, or a pair of numbers,
or a banana, or the Eiffel tower, or even Richard Nixon. Likewise for a.
Let us consider application of this abstraction. Database diagram and control
systems diagram are presented in figure 6
Figure 6: Database and control system diagrams
Common features of these diagram are objects and arrows as abstract objects.
Figure 7 presents database and control systems diagram in single framework
(There is no one to one map).
Now we would like to integrate both diagrams. Integrated diagram is presented
in figure 8 Presented on 8 diagram has following meaning. Database contains
recorded input signals of control systems. This diagram enable us to define
response of control system.
4

Figure 7: Database and control system diagrams in single framework
Figure 8: Integrated database and control system diagram
5

4 Present day state
Explanation of idea usefulness is difficult without any implementation. This
idea shall find further development. However a lot of features are already im-
plemented. These features are presented in figure 9. Presented in figure 9
Figure 9: Hierarchy of assemblies
scheme reflects only part of implemented features. Source code can be down-
loaded from http://www.mathframe.com. It is worth to note whole product is
not a sum of presented in figure 9 features only. These features can interact and
interaction make product much more powerful. This thesis will be shown below
by examples. This hierarchy can inspire some questions. One of reasonable
question is: ”Why we need abstract physical field library?” Now this software
supports physical fields in 3D space. However this software is declared as univer-
sal and should support 2D physical fields in future. And 2D fields library shall
6

be inherited from abstract physical field library. Universality had been provided
from the very beginning of development. Demo applications show prospects of
further development.
5 Elementary examples
Examples of this section are not not related to real science and engineering
problems. These examples are rather textbook which is very facile for idea
explanation.
5.1 Physical fields
One physical phenomenon acts to another one and there is backward depen-
dence. This thesis can be exhibited by example presented in figure 10. We
Figure 10: Charged balls
have two charged balls Ball 1 and Ball 2. Electrostatic force which act to
Ball 2 depends on relative position Ball 2 with respect to Ball 1. Otherwise
the relative position as time function depend on motion of Ball 2 and there-
fore relative position depends on electrostatic force. Common consideration of
6D motion and physical fields make software much more effective. Now we
would like simulate motion of Ball 2. Simulation scheme is presented in figure
11. Left part of this picture represents electrostatic field of Ball 1. Objects
Figure 11: Charged balls motion simulation
7

Coord, Field calculator and Field vector provide calculations of next for-
mula of electrostatic intensity:
E =
kr
|r|3 ;
where r is 3D vector of relative position with respect to charge, k is coeffi-
cient which depends on charge of Ball 1 and system of units. This calcula-
tion is separated for performance issue. Object Coord calculates k|r|3 , object
Field calculator calculates components of 3D vector kr|r|3 and Field vector as-
semblies these components into vector. All these calculation are used by Field
object. Properties of the Field objet are presented on figure 12.
Figure 12: Properties of Field object
These properties have following meaning. First of all field parameter is output
vector of Field vector. Figure 13 explains meaning of ”covariant” term. If
3D vector is not covariant then its components depend on sensor position only.
Covariant vector components depend on both orientation and position. Values
of components are projections of geometric vector to sensor’s axes of reference.
Figure 13 presents two orientations of sensor: blue and green. Projections of field
vector A are different for these different orientations. So we have 3D covariant
physical field. The Sensor object is a sensor of the field. The Scalars object
provides components of field vector obtained by the Sensor object. These
components are used in following motion equations of Ball 2:
x˙ = Vx;
y˙ = Vy ;
z˙ = Vz ;
V˙x = aEx;
V˙y = aEy;
V˙z = aEz .
8

Figure 13: Covariant field
where x, y, z are coordinates of Ball 2 and Vx, Vy, Vz are components of its
velocity. Coefficient a depends of charge of Ball 2 and system of units. These
motion equations are contained in Motion object. Then coordinates x, y, z
are used by moved reference frame Sensor′s frame. The Sensor object is
installed on Sensor′s frame. So we have backward dependence. Motion and
therefore current position of Sensor′s frame and Sensor depends on current
field value. Otherwise current field value depends on current position. Let us
make situation more complicated. New situation is presented on figure 14 Here
we have installed Field on Field′s frame and added new object Relative. The
Relative defines relative motion parameters of Sensor′s frame with respect
to Field′s frame. Relative distance is indicated by Chart object. Physical
picture remains the same. We have added indication only. Now let us install
Ball 1 on moved platform as it is presented in figure 15
Simulation of this situation is presented on figure 16.
Now Field′s frame is moved and Motion of ball 1 object defines motion low.
The time dependence of distance between Ball 1 and Ball 2 has been changed
by following factors. First of all now Ball 1 which is source of Field is moved.
Its own motion influence on relative distance. Secondly motion of field source
influence on field intensity near Ball 2. So absolute motion of Ball 2 will be
changed. This factor also influence on the distance. These facts are physically
evident. I would like to exhibit facilities of such approach from point of view
of software user. The user simply has added motion to Ball 1 and all other
dependent factors had been automatically taken into account. This facility is
9

Figure 14: Charged balls motion simulation with relative measurements
Figure 15: Charged balls with moved ball 1
Figure 16: Charged balls motion simulation with moved ball 1
10

impossible without integration.
5.2 Space aerodynamics and digital image processing
The key feature of space aerodynamics is that spacecraft interacts with molecules
which do not collide with each other. Therefore aerodynamic force depends on
visible area and does not depend on other parameters of spacecraft shape. We
can use digital image processing for space aerodynamic calculation. Let us con-
sider it for space aerodynamics. The image of the Mir orbital station is presented
on figure 17. This photo should be filtered for space aerodynamics usage. This
Figure 17: The Mir orbital station
filtering (digital image processing) is presented on figure 18. The Prototype
Figure 18: The Mir orbital station digital image processing
object contains source image and Result contains filtering result. Other objects
contain necessary math. This sample presents main advantage of integration.
Software devoted to space technology only is not effective without digital image
11

processing. Otherwise digital image processing is not effective without advanced
math.
5.3 Algebraic topology
Algebraic topology is not yet everyday tool of engineer or scientist. Now this
branch of science looks rather as exotic. However exotic tasks are good tests
for integrability and universality. The ”Modern math” has been developed as
test of prospects of Category Theory approach. In this chapter calculation of
different topological invariants [2] is considered. Let us consider Klein bottle K
and real projective space RP 3 (figure 19 Homology groups of these spaces can
Figure 19: Klein bottle and projective space
be calculated as homology of following chain complexes [2]:
... C2 C1 C0;w
∂3
w
∂2
w
∂1
Chain complex of Klein bottle K and real projective space is presented below:
Z Z Z Zw0 w2 w0
The application representation of it is shown in figure 20
Figure 20: Klein bottle chain complex representation
Chain complex of real projective space RP 3 is presented below:
Z Z × Z Zw
( 11 )
w
(1,1)
Chain complexes of both spaces are presented in figure 21.
Now we can calculate homology and cohomology groups, homology with coef-
ficients and other invariants. More details you can find at Category Theory
project http://categorytheory.sourceforge.net/.
12

Figure 21: Klein bottle chain complex representation
6 Realistic samples
Here we consider more complicated samples which are related to real engineer-
ing problems. This problems include following disciplines:
- advanced mechanics;
- processing of signals;
- statistics;
- system identification;
- control theory;
- celestial navigation;
- astronomy;
- geomagnetism;
- space aerodynamics;
- digital image processing;
- virtual reality. All these samples can be downloaded from http://www.codeproject.com/KB/architecture/g
6.1 Advanced mechanics
Space technology provides good samples of advanced mechanics. Orbital station
(figure 17) is a very complicated mechanical object. It is not rigid body. It has
solar cell panels. These panels are elastic. The station is stabilized by gyros.
Moreover station configuration is not constant. The ”Mechanical aggregate”
library had been developed for simulation of similar aggregates. The library
contains aggregate designer. Why aggregate designer? Indeed mechanical equa-
tions are well known long time ago. But software development for simulation
of complicated mechanical objects is not quite easy task. Aggregate designer
make this task much easier. Aggregate designer is integrated into framework.
This fact enables us provide interpretability of mechanics with physical fields.
So it is easy to simulate action of magnetic fields on mechanical objects. I will
consider this task below. Now we would like to create mechanical model of
spacecraft from models of its modules. Typical spacecraft module is schemat-
ically presented in figure 22 This module has own coordinates system OXY Z.
Also it has places of connections. We can connect other modules to this module.
Behavior of module is defined by following kinematic parameters:
- radius vector r;
- velocity V ;
- orientation quaternion Q;
- angular velocity ω.
13

Figure 22: Spacecraft module
But module is not rigid in general. And these parameters are not parameters
of module. These parameters are rather parameters of one point of module. In
this article we suppose that these parameters are parameters of origin of OXY Z
coordinates system. Since module is not rigid it has additional degrees of free-
dom. These degrees of freedom can be interpreted as generalized coordinates
qi (i= 1,...,n). Instant state of module is defined by following parameters: r,
Q, q1, ..., qn, V , ω, q˙1, ..., q˙n. This parameters will be named state variables.
Parameters V˙ , ω˙, q¨1, ..., q¨n will be called accelerations. Mechanical equations
define accelerations by state parameters. Accelerations near connection can be
defined by following way:
ω˙i = εi + Pωi V˙ + Qωi ω˙ +
∑
k
Rωik q¨k; (1)
V˙i = ai + PVi V˙ + QVi ω˙ +
∑
k
RVik q¨k. (2)
where i is number of connection. Other variables are matrixes which depend
on state variables. Connection of two modules is presented on figure 23. Both
Figure 23: Connection of two modules
modules have equal acceleration near connection. First module acts to second
one by force F12 and mechanical momentum M12. Similarly second module acts
to first one by force F21 and mechanical momentum M21. These forces and
momentums satisfy following Newton equations:
F21 = −F21; (3)
14

M21 = −M21. (4)
Mechanical equations of module can be represented by the following way:
V˙ = a +
∑
i
DViFi +
∑
i
EViMi; (5)
ω˙ = a +
∑
i
DωiFi +
∑
i
EωiMi; (6)
q¨k = a +
∑
i
KkiFi +
∑
i
LkiMi. (7)
In these expressions accelerations are independent variables. Fi (Mi) is force
(mechanical momentum) of i- h connected module. Other vector and matrix
parameters depend on state variables. Suppose that m - h connection place
i-h module is connected to n - h connection place j-h module. Then we have
following evident relations:
V˙im = V˙jn; (8)
ω˙im = ω˙jn; (9)
Fim = −Fjn; (10)
Mim = −Mjn. (11)
Expressions (1) - (11) are linear by accelerations system of equations. This sys-
tem is fully defined and therefore can be solved. In result we have mechanical
equations of whole aggregate. It is worth to note that this system is redun-
dant. If n1 (n2) is number of freedom degrees of first (second) module then
system has n1 + n2 degrees of freedom. However aggregate has n1 + n2 − 6
degrees of freedom. The exist software version that avoid this redundancy. But
I will not describe it in this article. Aggregate designer provides equations of
full aggregate automatically. Coefficients of (1) - (11) equations are inputs of
aggregate designer. In general these coefficients can depend on states of mod-
ules. There exist a lot of variants. But we can abstractly define calculation of
these coefficients and then provide different implementations. Following types
of mechanical modules are implemented:
- absolutely rigid body;
- elastic console;
- flywheel;
Equations of rigid body are well known and are not present them here. In con-
text of aggregate designer rigid body has following properties:
- mass m;
- momentum of inertia J ;
- number of connections;
- positions and orientations of connections.
These properties can be edited. Elastic console body is a mechanical system of
infinite degrees of freedom. Usually math model of this object contains finite
15