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