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
elements.
This is a slight generalization of Matt's characterization, in that it
recognizes the existence of parts with subfunctions, without requiring
substitutability.
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?
-Ed
