Dear Ed, (01)
Agreed, but just one thing... (02)
> This is a slight generalization of Matt's characterization, in that it
> recognizes the existence of parts with subfunctions, without requiring
> substitutability (03)
MW: Can you give an example of a system with parts that were not
substitutable? (04)
Regards (05)
Matthew West
Information Junction
Tel: +44 560 302 3685
Mobile: +44 750 3385279
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.matthew-west.org.uk/ (06)
This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
Hertfordshire, SG6 3JE. (07)
> -----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
>
> --
> Edward J. Barkmeyer Email: edbark@xxxxxxxx
> National Institute of Standards & Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
> Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
> _________________________________________________________________
> 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
> (08)
_________________________________________________________________
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 (09)
|