> > 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