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