ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Ontological Means for Systems Engineering

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Jack Ring" <jring@xxxxxxxx>
Date: Wed, 28 Jan 2009 10:18:28 -0700
Message-id: <13714CFA5F864E1D96054B46F92A3E33@OfficeDell>
A useful analog may be James Grier Miller's model of a human cell in which he identifies 19 kinds of "operators" within the cell.
 
A system consists of operands and operators arranged 'just so' to achieve the Measure(s) of effect-iveness assigned to the system. In contrast, Systems Engineering is part of (ideally about 5% of) a system that generates systems.
 
Accordingly, systems engineering can be modeled as an ordered set of operands (knowledge) and operators (discovery and exchange), then, because it is performed mostly by humans, it must contain further operators of the error detection of correction kind,
 
Hierarchies can be used but always decrease parsimony and increase ambiguity. Better we should learn to think of multi-factor transfer functions.
 
Soooo, for the ontology of SE-speak, what are the equivalent of J.G. Miller's 19 operators in a human cell.  'Is-a' doesn't suffice and 'has-a' implies personification --- robots hate that. ;-)
 
Jack Ring
 
ps. having designed intake system for successful race car engines I can report that the nature of the relationship among throttle, intake valve, piston, exhaust valve and exhaust pipe shape is best approximated by discontinous, compressible flow --- the same category of relational that characterizes workgroups having frontal lobes. Ants and bees are simpler.
----- Original Message -----
Sent: Wednesday, January 28, 2009 9:22 AM
Subject: Re: [ontolog-forum] Ontological Means for Systems Engineering

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



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ 
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ 
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>