[Top] [All Lists]

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

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Anders W.Tell" <opensource@xxxxxxxxxxxxx>
Date: Sat, 24 Jan 2009 13:38:48 +0100
Message-id: <497B0BD8.60606@xxxxxxxxxxxxx>

Interesting, what you describe seems very similar to SBVR approach where they talks about communities and separates semantic communities from speech communities. So in the examples provided, the 'Term's "System","System" and "Capability Configuration" occurs in three different 'Vocabularies' that are owned by three different 'Speech Communities', and all three represents the same 'Concept' in a single 'Semantic Community' where meaning corresponds to 'Thing's (which could also be stored in a SBVR concrete syntax formated file)

All in all a very nice and explainable way to keep track of 'Term's, members of a Name Type and 'Concept's and 'Thing's

Would be very interesting to get your opinion if SBVR could be used to express most parts of IDEA and BORO?


Ian Bailey wrote:
Thanks Ed. Now we can add yet another class, defined by the extent Ed
suggests, give it a name "System" and make that name a member of the
AP233-SysML Name Type. 

The point I'm trying to get across is that lots of people call different
things "system". We have now identified the extent of four different
classes, which intersect, and each is named "System", but each name System
belongs to a different name type. The one that is named "system" by the
Canadian Defence Dept. is also named "Capability Configuration" in MODAF. 

Anyone else want to identify a different class and call it "system"  ?

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ed Barkmeyer
Sent: 23 January 2009 16:16
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontological Means for Systems Engineering

I strongly suggest that we stay carefully on the topic that Andreas 
raised.  'Systems engineeering', as an engineering discipline, is about 
_artificial_ things.  So its definition of 'system' is constrained to 
such things.  While there are certainly "systems" in nature (the 
argument for 'intelligent design'), we don't engineer them, although we 
may analyze them to provide engineering insights. If we waltz off into 
the philosophical question of what a 'system' may be, we have lost sight 
of the objective.

Matthew West wrote:

The two things that characterise a system for me are:

1.   It has a function/capability/purpose.

2.   Has parts that can be replaced by functionally equivalent parts.

A project in which I was engaged about 7 years ago, an outgrowth of 
which was support for ISO 10303-233 and SysML, defined 'system' as:
   a complex of software, hardware, and human resources that jointly 
accomplishes one or more business functions. A system may be 
pre-designed or arise ad hoc by action of one or more of the 
participating human or software resources.

And I should be careful to say that the intent of the definition is that 
a system is a complex of any combination of software, machines, and 
humans.  There is no requirement for a system to have all three types of 

This is a slight generalization of Matt's characterization, in that it 
recognizes the existence of parts with subfunctions, without requiring 

And this leads to a concept that is critical to systems engineering, but 
is only assumed in the above characterizations: subfunction.  Borrowing 
from INCOSE, the NIST paper defines:
   System design =
(1) a specification of the structure of the system, ...
(2) a breakdown of system functions into subfunctions assigned to 
nominal component subsystems, coupled with a specification for the 
information and materials that must be available at the component 
interfaces in order for the subfunctions to be accomplished.

Systems engineering is about WHAT components do, HOW that is part of the 
intended system function, and HOW they relate to each other.  It is also 
about capturing constraints on the system and how those constraints are 
allocated to (or interpreted for) the components.  It is the 
'encapsulation' of HOW the components do WHAT they do, within the given 
constraints, that creates substitutability.

The other idea that is commonly associated with a 'system' (from the 
'systems engineering' point of view) is heterogeneity, either in the 
nature of the parts, or in the collection of views (specifications of 
structure) that are required to understand the implementation of the 
functions.  (One can leave the design of a purely mechanical system to 
mechanical engineers, or a purely electrical system to electrical 
engineers.  It is only when there is a mix of human parts, software 
parts, major electronic/electrical components, and major mechanical 
components that it becomes a 'systems engineering' project.)

Back to Andreas' original point, I have never seen an ontology for 
systems engineering concepts.  It was the original goal of INCOSE (about 
10 years ago) to organize the knowledge of experienced systems engineers 
into a real engineering discipline, one that could be taught.  What Matt 
and Ian describe is an activity that was ongoing early in that effort, 
and I personally don't know whether INCOSE (as a body) believes it has 
achieved its goal.  Ontology development is about engineering existing 
knowledge -- it presumes that the knowledge to be engineered is 
agreed-on by the community it intends to serve.  In systems engineering, 
are we there yet?



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>