The document discusses systems engineering foundations and introduces several key concepts, including metaclasses, states, functions, and class hierarchies. It provides examples of how these foundational ideas can be applied, such as defining system states using state diagrams and organizing functions according to states. Studying SE foundations is suggested to provide insights, improve current practices, and help develop new capabilities.

1. Crossroads of America Chapter
Foundations of Systems Engineering Special Interest Group
Does Our SE House Have a Foundation?
Presented to: Crossroads of America
Chapter Meeting, March 11, 12, 14, 2002
Systems
By: Bill Schindel, ICTT
Engineering
1
Foundation

2. An introduction to SE Foundations
• What do we mean by SE foundations?
• Introduction to SE foundation concepts
• Example results and implications
• Our chapter’s Foundations of Systems
Engineering SIG
Copyright © 2002 W.D. Schindel, System Sciences, LLC. 2

3. What do we mean by SE foundations?
• What we do not mean by “foundations”:
– Not just basics for new initiates--important to experts, too
– Not a commercial standard
– Not a methodology for performing systems engineering
– Not a process reference or capability model
– Although foundations can improve support for all of these
• So, what is left? Foun
datio
n ?
3

4. What do we mean by SE foundations?
• What happened when “foundations” were
studied in other technical fields:
– Mathematics . . . (Godel)
– Physics . . . (Boltzmann) ?
– Computer science . . . (Turing) Found
ation
– Theoretical biology . . . (Rosen)
• Moving from intuitive practice to formal
understanding created new insights:
– Including some surprising discoveries
4

5. What do we mean by SE foundations?
? ?
• Picking the right research questions:
– the following questions have aided our
?? ?
research into foundations of systems
engineering . . . .
??
Found
ation
5

6. Found
at ion
?
Foundational questions
• Is there a smallest set of formal ideas from which the rest of
systems engineering can be generated (or expressed in)?
• If so, what are those formal ideas?
• If not, why not?
• What is the formal structure and implication of the web of ideas
underlying systems engineering thought and language,
methodologies, process reference models, artifacts, and
problems ?
• Are there any surprises compared to classical system engineering’s
traditionally intuitive or less formal approaches to these ideas?
6

7. Found
at ion
?
Foundational questions
• In performing practical, real-world systems engineering, what
problems, fundamental limitations, and possibilities can we
predict will be encountered because of the underlying
foundations upon which systems engineering rests?
• As we create integrated networks of automated SE tools,
what are the standard conceptual objects they must operate
on and exchange with people and each other?
• What do these foundations suggest about the future of
systems engineering?
• What research and practical activities are suggested to
advance current SE practice and future capabilities?
7

8. Found
at ion
?
Foundational questions
• What are the foundational ideas that link Systems
Engineering to other fields in the Arts and Sciences?
• How is systems engineering related to the broader area of systems
sciences, complexity, and language?
• If we aim to utilize systems engineering in diverse areas
not traditional to SE origins, how must these be
conceptually mapped, and with what impact?
8

9. Found
at ion
?
Foundational questions
• What conceptual road maps of simplified foundational
ideas can be used to more easily or effectively
understand, perform, manage, or conform to current,
complex, or specific SE methodologies, standards, and
processes?
• What principles are needed to apply systems
engineering to more complex problems than the design
of traditional systems; e.g.,
• As in the engineering of globally optimized families of
configurable systems (product lines)?
• Or the engineering of high intelligence systems?
9

10. Examples of SE foundation concepts
• Metaclasses • Requirements and Design
– Systems • Hierarchy
– States • Configuration and Specialization
– Functions • Patterns
– Features
• Intelligence
– Interfaces, Systems of Access,
Boundaries • Views of Models
– Views • Complexity; Simplicity
10

11. Model-based systems engineering
• Model-based systems engineering is an emerging approach to
systems engineering:
– See www.incose.org
• Uses explicit models where previously informal, intuitive,
natural language prose (e.g., English) of documents was used
• Not all model M odel M o d e le d T h in g
interpreters need be
AP 233 M o d e l In te rp re te r
human
P ro c e s s o r F a rm 11

12. Introduction to the SE Metaclasses
• SE Metaclasses are formally defined classes
of foundational objects from which are
constructed models of systems:
– models of the systems we engineer
– models of the systems engineering process
– models of project stakeholder success objectives
– other extended models
– including models of the properties of all these
12

13. Introduction to the metaclasses
• Metaclasses are related in a formal web of explicit
conceptual relationships; e.g.,
System
System
System
(physical systems) attribute
Feature
Feature
Feature
Design
attribute
State
Component attribute
attribute
Function
attribute
Interface
attribute
System of
(logical systems) Access
attribute
View
Role attribute
attribute
13

14. Example Metaclasses
The System Metaclass
• A System is a collection of interacting
Components :
System
Relationships
Components
18

15. Example Metaclasses
Systems may be any technology
• Mechanical
• Electronic
• Software
• Chemical
• Thermodynamic
• Human organizations
• Biological
19

16. Example Metaclasses
Not everything that has parts is a system
• For components to “interact”, there must be an
idea of “state” and relationship between states of
components:
– Two components interact if the state of at least one is
impacted by the interaction having occurred
– A book, a piece of music, or a photograph have their
own components, but not direct interactions between
them
• This view distinguishes the engineering view of
systems from “systems” in some other fields.
20

17. Example Metaclasses
Containment Hierarchy: Subsystems
• A Component can itself be a System
• This just means the Component has Components.
• This makes it a Subsystem.
• Can continue indefinitely.
System
Subsystem
23

18. Example Metaclasses
Logical Systems
• A Logical System is a system defined based solely upon its
required functionality or behavior as seen by external systems
interacting with it, and not based upon how it achieves that
functionality internally or its identity or physical make-up.
Environment
System
24

19. Example Metaclasses
Logical Systems
• Example of Logical System:
– Engine System: An Engine System converts atmospheric air
and chemical fuel into rotating mechanical power for use by
other machine subsystems.
Environment
System
26

20. Example Metaclasses
Physical Systems
• A Physical System is a system defined based upon its
physical identity or physical composition. Physical
Systems may be given proper names, such as names
of commercial products, corporate systems, people,
organizations, buildings, etc.
27

21. Example Metaclasses
Physical Systems
• Examples of Physical Systems:
– Toyota Camry Model XLE Automobile
– Caterpillar Model 3406 Diesel Engine
– Program Module 1750
– Part Number EC3445 Electronic Module
28

22. Example Metaclasses
The State Metaclass
• States are situations, conditions, or circumstances about
systems that occur during some period of time.
• The required time history of possible states of systems can
be described using finite state machines.
• State transition diagrams or (in UML) state charts can be
used to graphically describe these state machines.
State B
causal event 2
causal event 1
State A State C
causal event 3
30

23. Example Metaclasses
States
• State transitions are graphically illustrated links indicating
the passage of a system from one state to another.
• Events are occurrences in time.
• Events can be modeled as the cause of state transitions, by
labeling state transition lines with event names.
State B
causal event 2
causal event 1
State A State C
causal event 3
31

24. Example Metaclasses
Lawn mower example
la w n m o w e r s ta r te d
S ta r tin g
S e r v ic in g
s e r v ic e c o m p le te
I d lin g
s e r v ic e r e q u e s t d is e n g a g e m o w in g
s t a r t r e q u e s t r e c e iv e d
r e c e iv e d
engage
Shut D ow n
N o r m a l M o w in g m o w in g
s h u t d o w n in itia te d
n o r m a l s h u t d o w n c o m p le te d
S h u t tin g D o w n
o v e r h e a t r e c o v e r y c o m p le te
o v e r h e a te d s h u td o w n c o m p le te d
O v e r h e a t R e c o v e r in g
L a w n m o w e r S ta te
32

25. Example Metaclasses
The Function Metaclass
• A function is an interaction of systems.
– Systems fill functional roles in these interactions.
• Example:
– Function = Start Mower
• Roles = Operator, Controller, Mower Clutch, Engine
Operator Controller Mower Clutch Engine
1: Request start
Function: Start Mower 2: Verify disengaged
3: Acknowledged
4: Start
5: Started
6: Signal running
36

26. Example Metaclasses
Functions describe “what” happens
• Systems describe “who” performs interactions.
• States describe “when” interactions occur.
• Functions describe “what” the interactions are.
37

27. Example Metaclasses
Functions describe outcomes
• A function describes what must occur as seen by
those outside a subject system.
• So, a function describes requirements on the
subject system in its external interactions.
• These requirements are outcomes of the functional
interaction.
• The function does not describe how a subject
system accomplishes the requirements internally.
– That would be design, a later subject.
38

28. Example Metaclasses
Functions describe outcomes
• This means that we have been able to describe
functional requirements as relationships between a
system and its external environment.
• This is a very important step toward modeling
patterns of functional requirements in families of
configurable systems.
• It is the core idea of Relational Non-Algorithmic
(RNA) models of functional requirements.
• It is borrowed from mathematical physics, as in
Lagrangian interaction relationships.
39

29. Example Metaclasses
Organizing functions with states
• Functions can be associated with states.
– This is a way to indicate what functional interactions are
required to occur during certain situations (that is,
“when” they should occur in situational time)
– This is a way to connect the (software engineering) “use
case method” to state and function modeling techniques
1
– This is a way to formalize operational scenarios, as in
C4ISR, etc.
(1) -- Other states show that an interaction actually occurred. Recall that the meaning of “interact” requires that the states of
some components be impacted. These are “smaller” than the “when” states above, and are encountered in design
decomposition.
40

30. Example Metaclasses
Lawnmower example
Starting Mowing
Shutting Down
Functions:
Functions:
1.Cut grass (to operator
1. Start (w/i 10 seconds of turning Functions:
determined length)
key) 1. Disengage blades
2. Noise control (conform
2.Check Starting Interlocks (blades 2. Shut down engine
to ASPE 102.3 noise
must be disengaged)
guidelines)
3. Noise control (conform to ASPE
4.Emission control
102.3 noise guidelines)
(conform to EPA 11.2
4.Emission control (conform to EPA
emission guidelines)
11.2 emission guidelines)
41

31. Class hierarchies and patterns
• Product evolution Capturing new
core value
while maintaining Evolve Slower
corporate asset Corporate
Product
Architecture
• High leverage Family of
competitive Product Lines
configurability Individual
Configurations Harvesting
Supported Evolve Faster
benefits
60

32. Class hierarchies and patterns
• Class hierarchies create patterns for all the metaclasses:
– systems
– states Lawnmower
Lawnmower
– features
– functions Walk-behind mowers
Walk-behind mowers Riding mowers
Riding mowers
“is a type of”
– interfaces
– views Push mower
Push mower Self-propelled mower
Self-propelled mower Rear engine rider
Rear engine rider Tractor
Tractor
– etc.
M3
M3
Push mower
Push mower M5 M17
M17 M 19
M 19 M 23
M 23
M5 M 11
M 11 M 13
M 13
Wide cut
Wide cut Self-propelled Self-propelled Rear engine
Rear engine Lawn tractor
Lawn tractor Garden
Garden
Self-propelled Self-propelled
self-propelled
self-propelled rider
rider tractor
tractor
61

33. Class hierarchies and patterns
• This allows high-productivity global management of
patterns across families of configurable systems (product
lines).
• Gestalt Rules™ describe patterns that are to be maintained
across product lines or families, providing a pattern
calculus for measuring pattern conformance.
62

34. C la s s H ie r a r c h y o f D y n a m ic P r o c e s s M o d e ls (F in ite S ta te M a c h in e s )
A
M o s t A b s tr a c t S u p e r c la s s B
P ro c e s s M o d e l
D y n a m ic M o d e l
(F S M )
B1 S u b c la s s in g :
M o r e S p e c if ic S u b c la s s A1 A1 T r a je c to r y a n d
P r o c e s s M o d e ls B2 B1 S ta te S p lit tin g
B3
E v e n M o r e S p e c ific B1A B2B
S u b c la s s P r o c e s s
A1A
M o d e ls
A1A
B2A B2D B2C B1A B1B
A1A
B3A B1A
63

35. Sample results and future implications
• Foundation Metaclasses have improved the understanding of SE experts and
permitted the rapid development of SE capabilities for entry level engineers.
• Multi-roled functions provide a more explicit framework for negotiating
interfaces across subsystems.
• We have used a common families-of-systems product line approach to model-
based systems engineering, across domains including telecommunications,
automotive and heavy equipment, medical, chemical, maintenance, and business
processes.
• We have adapted a meta-methodology (Systematica™) to the local corporate
processes and multiple vendor system engineering tools in different projects,
domains, and client organization’s standard processes.
• Configuring this to scalable light weight and heavier processes permits rapid
specification without giving up the benefits of discipline and risk management.
• We are working on model-based systems engineering applications to
implementing C4ISR, CMMI, Six Sigma, and other process modeling and
improvement frameworks, by contributing objects to count (measurable models).
64

36. Sample results and future implications
• Model-based systems engineering enables more sophisticated measurements:
– Construction-oriented specification metrics for process management
– Family Entropy for product line management
– Return on Variation™ for product lines
– Gestalt Rule™ conformance for architectural adherence
• Model-based systems engineering prepares the organization for sharing of
information across tools and systems of engineering and other organizations (e.g.,
AP233)
• Placed requirements on a non-prose based modeled basis, using functional (RNA)
relationships
• Proven in a common model of intelligence, control, and management that applies
across the embedded systems of disparate domains
• Model based systems engineering opens the door to future automation of design
synthesis and evaluation.
• Solved conundrums confusing to many engineering processes (mixed hierarchies,
logical and physical systems, role negotiation, etc.)
65

37. The Foundations of Systems Engineering SIG
• We are looking for people who want to join our chapter’s
Foundations of Systems Engineering Special Interest Group:
– SE practitioners to share their problems or ideas
– Researchers, faculty, others to collaborate
– New systems engineers, students, who want to discover and contribute
– Managers and leaders to contribute challenges and applications
• Current expertise is very welcome, but not required to join:
– This is an emerging area--everyone is learning
– All you have to do is engage in the interaction of the SIG
• We have set up a discussion group thread for this SIG on the
chapter web site:
– www.incose-coa.org
– An initial white paper to stimulate discussion is also located there. 66

38. Chapter Web Site Foundations of SE SIG Page
FOUNDATIONS OF SYSTEMS ENGINEERING
In spite of having been practiced in some areas for fifty years, systems engineering is
still new and emerging. Even the experts readily admit that they are still learning about
the core subject. The Foundations of System Engineering” SIG, program, and web site
thread are not just interested in entry level basics of systems engineering—they are
about the foundational concepts that theoretically support systems engineering—
including both research and practice. This foundational approach is in contrast to more
complex roadmaps, standards, methodologies, and tools, that utilize these
foundations. From this foundation comes both basic understanding as well as future
theoretical structure.
To participate in the threaded discussion you may:
View the articles posted in the list
Post a new article (starting a new thread)
Search the articles for a word or pattern
PUBLISHED DOCUMENTS: This section is reserved for documents that are created
as a result of a discussion thread.
67

39. The Foundations of Systems Engineering SIG
• What you will gain
– Clarify, for others or for yourself, the foundational ideas behind
systems engineering, as it enters a new phase
– Learn about and contribute to model-based systems engineering
– Find practical ways to implement mandated standards
– Prepare your organization for interoperability of computer-based SE
tools and other information systems under AP233 and similar efforts
– Investigate ways to improve the productivity, effectiveness,
manageability of the systems engineering frameworks, processes, and
standards you utilize
– Find out answers to your questions, or help answer the questions of
others
– Networking: get to know others with similar interests
68

40. The Foundations of Systems Engineering SIG
• This chapter Special Interest Group can contribute to and
connect you with exciting area emerging in our field:
– Creating, operating, and evolving complex engineered systems of all
types is one of society’s most important endeavors.
– Some of the world’s most important systems are engineered,
manufactured, or operated in our two-state region.
– Some of the world’s best schools and research in systems-related
disciplines are in our region.
• Your participation in the Foundations of Systems Engineering
Special Interest Group is sincerely invited!
• Consult the SIG web site discussion group and register your
interest.
69

41. Join our SIG! Thank you!
• Bill Schindel
ICTT, Inc. and Systems Sciences, LLC
100 East Campus Drive
Terre Haute, IN 47802
schindel@ictt.com
812-232-2062
(A more complete set of these slides is on the
Foundations SIG part of the chapter web site.)
Systematica, Gestalt Rules, Return on Variation are trademarks of System Sciences, LLC.
Copyright © 2002 W.D. Schindel, System Sciences, LLC. 70

42. Bibliographic Sampler
1. W. Schindel, “System Engineering: An Overview of 11. Humphrey, Watts S., Managing the Software Process, Addison
Complexity’s Impact”, SAE International, Technical Paper Wesley, New York, NY, 1989.
962177, October, 1996.
12. Humphrey, Watts S., A Discipline for Software Engineering,
2. W. Schindel and G. Rogers, “Methodologies and Tools Addison Wesley, New York, NY, 1995.
Supporting Continuous Improvement”, to appear in: Journal of
13. Myers, Isabel Briggs, Gifts Differing, Consulting Psychologists
Universal Computer Science, March, 2000.
Press, Inc., Palo Alto, CA, 94303
3. W. Schindel, “The Tower of Babel: Language and Meaning in
14. Psychology of Programming, Hoc, J.-M., Green, T.R.G.,
System Engineering”, SAE International, Technical Paper
Samurcay, R., and Gilmore, D.,J., eds, Academic Press, Ltd.,
973217, November, 1997.
London, U.K., 1990.
4. Systems Engineering: The Journal of the International Council
15. Arnheim, Rudolf, Visual Thinking, U. of California Press,
on Systems Engineering—Special Issue on Capability Maturity
Berkeley, CA, 1969.
Model Integration, John Wiley Publishers, March, 2002.
16. Arnheim, Rudolf, Toward a Psychology of Art: Collected
5. CMMI Tutorial, SEI, Carnegie Mellon University, Pittsburgh,
Essays, U. of California Press, Berkeley, CA, 1966.
PA, September, 2001, www.sei.cmu.edu/cmmi/publications/
stc.presentations/tutorial.html 17. Arnheim, Rudolf, New Essays on the Psychology of Art, U. of
California Press, Berkeley, CA, 1986.
6. The web site of the International Council on Systems
Engineering: www.incose.org 18. Hebb, Donald O., The Organization of Behavior, John Wiley &
Sons Publishers, New York, NY, 1949.
7. “Processes for Engineering A System”, Electronics Industries
Alliance (EIA), Publication ANSI/EIA-632-1998, January, 19. James, William, The Principles of Psychology, Dover edition,
1999. Dover Publishing, New York, NY, 1980.
8. “Systems Engineering Capability Model (SECM)”, Electronic 20. Hayakawa, S. I., Language In Thought And Action, fifth
Industries Alliance (EIA), Publication EIA/IS-731-1, January, edition, Harcourt Brace Jovanovich, Publishers, Orlando, FL,
1999. 1990.
9. “Systems Engineering Capability Model Appraisal Method 21. Language, Thought, and Reality: The Selected Writings of
(AM)”, Electronic Industries Alliance (EIA), Publication Benjamin Lee Whorf, J. B. Carroll, ed., MIT Press, Cambridge,
EIA/IS-731-2, January, 1999. MA, 1956.
10. Bate, Roger, et al, A Systems Engineering Capability Maturity 22. Shastri, Lokendra, Semantic Networks: An Evidential
Model, Version 1.1, Software Engineering Institute, Carnegie Formalization and its Connectionist Realization, Morgan
Mellon University, Pittsburgh, PA, 1995. Kaufmann Publishers, Los Altos, CA, 1988. 71

43. Bibliographic Sampler
23. Pinker, Steven, The Language Instinct: How the Mind Creates 33. Glickstein, I. S., “Hierarchy Theory: Some Common Properties
Language, William Morrow and Co., New York, NY, 1994. of Competitively-Selected Systems”, PhD. Thesis, State U. of
New York at Binghamton, Systems Science Dept., Binghamton,
24. Chen, Peter, “The Entity-Relationship Model: Toward a Unified
NY, 1996.
View of Data”, ACM Trans. On Database Systems 1, 1(March),
9-36, 1976. 34. Pattee, Howard H., ed., Hierarchy Theory: The Challenge of
Complex Systems, George Braziller Publishers, New York, NY,
25. Booch, Grady, Object-Oriented Analysis and Design With
1973.
Applications, Second Edition, Benjamin Cummings Publishers,
New York, NY, 1994 . 35. Alexander, Christopher, A Timeless Way of Building, Oxford U.
Press, New York, NY, 1979
26. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen,
W., Object Oriented Modeling and Design, Prentice-Hall, New 36. Alexander, Christopher, et al, A Pattern Language: Towns,
York, NY, 1991. Buildings, Construction, Oxford U. Press, Oxford, New York,
NY, 1977.
27. Jacobson, I.,Christerson, M., Jonsson, P., Overgaard, G.,
Object-Oriented Software Engineering: A Use-Case Driven 37. Gamma, E., Helm, R., Johnson, R. , and Vlissides, J., Design
Approach, Addison-Wesley Publishers, New York, NY, 1993. Patterns: Elements of Reusable Object-Oriented Software,
Addison-Wesley, New York, NY, 1995.
28. Alexander, Christopher, Notes on the Synthesis of Form,
Harvard U. Press, Cambridge, MA, 1964. 38. Thompson, D’Arcy, On Growth and Form, Cambridge U. Press,
Cambridge, UK, 1961.
29. Abelson, H., and Sussman, G., Structure and Interpretation of
Computer Programs, MIT Press, Cambridge, MA, 1985. 39. Gerald M. Edelman, Topobiology: An Introduction to Molecular
Embryology, Basic Books, 1988.
30. Morowitz, H., Energy Flow In Biology: Biological Organization
As A Problem In Thermal Physics, Ox Bow Press, Woodbridge, 40. Lawrence, Peter A., The Making of a Fly: The Genetics of
CT, 1979. Animal Design, Blackwell Scientific Publications, Oxford, U.K.,
1992.
31. Prigogine, Ilya, From Being To Becoming: Time and
Complexity In The Physical Sciences, W. H. Freeman Co., New 41. Wolpert, Lewis, The Triumph of the Embryo, Oxford U. Press,
York, NY, 1980. New York, NY, 1991.
32. The Principles of Organization In Organisms: Santa Fe Institute 42. Robert Rosen, Anticipatory Systems: Philosophical,
Studies in the Sciences of Complexity, Vol XIII, Mittenthal, J., Mathematical & Methodological Foundations, Pergamon Press,
and Baskin, A., eds., Addison-Wesley Publishers, Reading, MA, 1985.
1992.
72

44. Bibliographic Sampler
43. Ferguson, Eugene S., Engineering and the Mind’s Eye, MIT 53. Rosalind L. Ibrahim, ed., Software Engineering Education,
Press, Cambridge, MA, 1992. Eighth SEI CSEE Conference Proceedings, Springer Verlag,
1995.
44. Miller, Arthur I., Imagery In Scientific Thought: Creating
Twentieth Century Physics, MIT Press, Cambridge, MA, 1986. 54. Edward Yourdon, Rise & Resurrection of the American
Programmer, Prentice-Hall, 1996.
45. Arnheim, Rudolf, Entropy and Art: An Essay on Disorder and
Order, U. of California Press, Berkeley, CA, 1971. 55. Boehm, Barry W., Software Engineering Economics, Prentice-
Hall, New York, NY, 1981.
46. Shaw, Mary and Garlan, David, Software Architecture:
Perspectives On An Emerging Discipline, Prentice-Hall
Publishers, New York, 1996.
47. Software Engineering Metrics, Martin Shepperd, ed, McGraw-
Hill, New York, NY, 1993.
48. Complexity, Entropy, and the Physics of Information: Santa Fe
Institute Studies in Sciences of Complexity, Vol. VIII, Zurek,
Wojciech H., ed., Addison-Wesley Publishing, Reading, MA,
1990
49. Leff, Harvey S., and Rex, Andrew F., eds, Maxwell’s Demon:
Entropy, Information, Computing, Princeton U. Press,
Princeton, NJ, 1990.
50. Hofstadter, Douglas, Fluid Concepts and Creative Analogies:
Computer Models of the Fundamental Mechanisms of Thought,
Basic Books, New York, NY, 1995.
51. Mitchell, Melanie, Analogy-Making As Perception: A
Computer Model, MIT Press, Cambridge, MA, 1993.
52. Kosko, B., Neural Networks and Fuzzy Systems: A Dynamical
Systems Approach to Machine Intelligence, Prentice-Hall
Publishers, Englewood Cliffs, NJ, 1993.
73