Hi Andreas,
In the dim and distant past, when I was editor ISO10303-233,
Harry Frisch from NASA Goddard was embarking on an ontology project. I left the
ISO work shortly after that to pursue setting up my own business, so never
really kept track. I also heard that JPL were doing something around this too,
but all my JPL contacts have either retired or moved on.
The scope of the IDEAS model is the enterprise architecture
frameworks of the various nations (e.g. DoDAF, MODAF, etc.). As a result, we’ve
had to do a bit on systems structure and behaviour. The big challenge in ontology
is to figure out what’s different about a system to any other physical
item. Why is a car considered a system, but a rock isn’t, for example. We
had a lot of debates around this in IDEAS meetings. You can easily ascertain
the extents of aircraft, armoured vehicles, etc., but the extent of the classes
each nation were calling system differed. The UK framework (MODAF) saw a system
as any kind of man-made object that had functionality (i.e. cars=yes, rocks and
humans = no). The Canadians were very specific that a physical object only
became a system when it was manned, maintained and ready to function – a narrower
set than the UK one. The US (DoDAF) description was similar to the UK but also
included humans/animals. So, we had three overlapping classes, each of which
was called “system” by different parties. By extensional analysis,
we worked out that what MODAF calls “CapabilityConfiguration” was
an exact match for the Canadian “System”.
The big challenges for ontology in systems engineering are the
ideas of Capability and Requirements. Capability (as defined by military folks)
seems to be about dispositions that certain classes of systems might have –
e.g. the ability to conduct long range strike, move troops around, etc. Requirements
management is a real can of worms though. To do this properly, and take into
account trade-off, you need to visit the murky worlds of Modal Logic and
Possible Worlds (David Lewis). It’s a pretty big piece of work to unpick a
fuzzy, imprecise subject like requirements and “ontologise” it.
Such an analysis might well pay dividends though, as billions of dollars are
lost every year throughout the world because of poorly stated and poorly
understood requirements.
I wouldn’t be surprise if INCOSE doesn’t have a
working group for ontology – they seem to have one for everything else.
Mind you, back when I was working with them they still couldn’t agree on
a definition for “system”, so don’t hold your breath.
Cheers
--
Ian Bailey
www.modelfutures.com
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Tolk,
Andreas
Sent: 23 January 2009 12:15
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: [ontolog-forum] Ontological Means for Systems Engineering
I would like to get some feedback on an application domain of
ontologies that has not been broadly covered in this forum. It is partly
connected with the discussions on "next steps in using ontologies as
standards," but has a different focus.
While
we often focus on what can we express with ontologies, the world becomes much
easier when we are talking about systems engineering. Systems are much smaller
than the world. They have a well defined number of parts or entities that
interact with each other to provide functionality.
In
the moment we provide these functions as services - and the idea is not limited
to IT services - it becomes important to describe the system as good as
possible ... and now ontological means come into play. Ontologies provide the
means to describe the systems, its components, functions, and even constraints
in form of concepts, entities, relations, and axioms. The nice thing is that
all these descriptions are machine understandable, and so they can be used to
identify potential supporting systems, select the best fit for the job, and
synchronize - or even orchestrate - the execution of several selected systems
in support of the common task.
We
can even go a step further and formulate requirements in form of ontological
_expression_. This will support verification and validation tremendously, and
also help to unambiguously specify what is needed. This allows to identify if
new developments are needed, or if a composition of existing services can
fulfill the requirement.
Are
there any examples of success stories in this direction already available? Are
there any journal publications on systems engineering using ontological means
supporting these ideas?
==================== ;-)
Andreas Tolk, Ph.D.
Associate Professor
Engineering Management & Systems Engineering
Old Dominion University