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
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