>
> Jeff
Schiffel ,
originally :
>
>
>
> Recall that the
original query from Andreas Tolk was the application of
ontologies
>
> in
systems engineering. I pointed out that systems engineering has quite a bit
to
>
> do
with complexity and hierarchy, part of the continuous mathematics.
>
>
PatH , in
reply :
>
Complexity theory uses analysis, of course, but hierarchies are discrete
structures.
True,
but this is not what I mean. An engineered system does something. It flies
through the air, or tells time, or performs other useful duties. An engineered
system has components. These are discrete structures. I do not mean, however,
that they are in a hierarchy of “is-a” relations. They are in a composition
relation to the whole, “part-of.” The hierarchy is found in how the parts work
together.
Since
an airplane or clock does something, the parts of the composition work together.
There is a process element present. An ontology for systems engineering should
take that into account. The parts work together in a presumably planned way. The
desired behavior of the system emerges from the interactions. In complex
engineering s , however, there
are many compositions. The interaction of these may be hard to predict, and
there may be undesirable and unexpected emergent behaviors.
The
way to understand emergent behaviors is by looking at the hierarchy of
behaviors. The tool is hierarchy theory, a subdiscipline of complexity theory.
Both are part of the continuous mathematics, of calculus. The emergent behavior
is in the dynamical system. Since a system or subsystem has components, the
services the components provide are hierarchical. The pistons in a gas engine
have no knowledge of the accelerator
functions , but the accelerator sends the pistons a command message
to speed up by means of the fuel injector. The pistons respond, but only to a
point limited by the piston and drive train design. The pistons thus constrain
the accelerator , although the accelerator
does not know how it was constrained, just that its command was
limited to a top threshold. This is a hierarchy of subbehaviors that together emerge
as one behavior to move the
person driving from one location to another.
A
systems engineering ontology that does not take performance into account is very
limited in terms of the purpose of the system’s planned use. Another way to look
at the situation is that ontologies are static. They lay on a page. But
designing a system must take into account states and transitions, dynamic
things. I suggest that the behaviors among components are better understood if
model as hierarchies of commands and constraints.
Regards,
--
Jeff Schiffel