090123
Andreas Tolk wrote:
[…]
I do not need
another description of the whole discipline of SE, I need to describe a
system with artifacts that can be read and understood by intelligent agents
to understand
- what the system provides
(interfaces/service access)
- what the systems consumes
(inputs)
- what the system produces
(outputs)
- what the system requires
(resources/can be modeled as inputs)
- what the systems controls
(controls/can be modeled as inputs)
- what the constraints for the
inputs/outputs etc. (ICOMs for the IDEF fans) are
- what processes need to be
synchronized (synchronization points)
- what processes need to be
orchestrated (a little bit more work than synchronization)
- what constraints exist for
services and processes
Based on this, I want to check
to systems if they can be composed. Normally, a set of challenges needs to
be solved, even with a good description of the system using mathematical
models and axioms (and there is the bad word again: logic):
- there will be differences in
resolution (properties of concepts differ in resolution, multi-resolution
problem)
- there will be differences in
scope (other concepts are used to describe the same thing, multi-scope
problem)
- there will be differences in
structure (same properties are used to define different concepts,
multi-structure problem)
... and then all of the
above.
If we look at the life cycle,
stages and phases can be supported by different systems ... and so
forth.
Nonetheless, if the system
designers use a standardized set of ontological means, we have at least a
common syntax (and I agree that this does not mean we have a common
understanding of terms as well), but we will be one big step
further.
What I am dreaming about is a
lambda-calculus for systems ... long way to go.
All the best
Andreas
==================== ;-)
Andreas Tolk,
Ph.D.
Associate
Professor
Engineering
Management & Systems Engineering
Old
Dominion University
------------------------------------------------------------------------------
Right on,
Professor,
Prof. Emeritus
Warfield tells us to think of a system in terms of Context,
Content, and Structure (to which I add Behavior).
Prof. Emeritus
Wymore tells us the think about the relationships between Context and
Content in terms of Input/Output, Performance, Techology, Cost, Test and
Tradeoff Gradient
Miles Burke
tells us the types of Content are People, Places, Things and
Activities.
We notice that
all 'definitions' of systems are in the present tense which means, to those
paying attention, that a system exists only while responding to a stimulus,
otherwise all you have is a configuration of assets.
Warfield tells
us to think in terms of Problematic Situation, underlying Problem System and
Problem Suppression System. The problem suppression system is what you want
to create.
Checkland tells
us to think in terms of an intervention goal, an intervention strategy and a
system that achieves intervention. Jonas Salk did that. The goal
(how we will know that the problem has been suppressed) also called Measures
of Effectiveness and Standards of Acceptance, This reflects the old
rule, "start with the end in mind."
Nothing is
hierarchy. All exists as a set of nodes, striving to respond to stimuli, in
a web of mediators.
The contribution of systems engineering are
a) languaging the project (the other 95% of the project staff who have to
make the damn thing then make it work), b) describing the problem
suppression system in its various stages of realization, and c) converging
creativity (called ECN's) to closure.
Seeing
the stages of a system as concepual, logical and physical doesn't
work very well, especially for systems that score high in
extent, variety and ambiguity (often mis-labeled CAS for Complex,
Adaptive Systems). Wymore suggests Functional, Implementable, Buildable,
Testable.
From the I/O relaitonship one can nominate artifacts
that the system must produce. Then the question becomes Can such artifacts
happen? An artifact is a system so the question becomes what People, Places,
Things, Activities and TIME will suffice to create said
artifact.
Then the question becmes, "How many, when, of these
assets will support all I/O demands?"
Now you are ready to put intelligence into your
agents. There will be three kinds. One works on adjusting the
gradients in the system model, a second works on adapting the pattern of
relationships among system content. A third works on co-evoling system
content consistent with context and internal assets.
All three must honor not only conservation of mass,
momentum and energy from the thermodynamics axis but also equivalent triple
constrants from each of informatics, teleonomics, economics and ecologics
constraints.
The final result, an emulatable model of the system,
is an ontoloty. Not the current kind which are taxonomies cluttered with
first order spaghetti code, but real ontologies.
Does this mean that the foregoing is the start of a
whole systems realization ontology?
Onward,
Jack Ring