1

Does Our SE House Have a Foundation?

Presented to: Crossroads of America

Chapter Meeting, March 11, 12, 14, 2002

By: Bill Schindel, ICTT

Crossroads of America Chapter

Foundations of Systems Engineering Special Interest Group

Foundation

Systems Engineering

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.

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

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)

– Theoretical biology . . . (Rosen)

• Moving from intuitive practice to formal understanding created new insights:– Including some surprising discoveries

Foundation

?

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

?? ?

??

? ?

6

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?

Foundation

?

7

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?

Foundation

?

8

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?

Foundation

?

9

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?

Foundation

?

10

Examples of SE foundation concepts

• Metaclasses– Systems

– States

– Functions

– Features

– Interfaces, Systems of Access, Boundaries

– Views

• Requirements and Design

• Hierarchy

• Configuration and Specialization

• Patterns

• Intelligence

• Views of Models

• Complexity; Simplicity

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

M odel M odeled Thing

M odel In terpreter

Processor FarmProcessor Farm

AP 233

• Not all model interpreters need be human

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

13

Introduction to the metaclasses• Metaclasses are related in a formal web of explicit

conceptual relationships; e.g.,SystemSystem

FeatureFeature

System

Feature

attribute

attribute

Functionattribute

Stateattribute

ViewattributeRole

attribute

DesignComponent

attribute

(logical systems)

(physical systems)

Interfaceattribute

System of Access

attribute

18

• A System is a collection of interacting Components :

Components

RelationshipsSystem

The System Metaclass

Example Metaclasses

19

Systems may be any technology• Mechanical

• Electronic

• Software

• Chemical

• Thermodynamic

• Human organizations

• Biological

Example Metaclasses

20

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.

Example Metaclasses

23

Subsystem

• A Component can itself be a System

System

Containment Hierarchy: Subsystems

• This makes it a Subsystem.• This just means the Component has Components.

• Can continue indefinitely.

Example Metaclasses

24

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.

SystemEnvironment

Example Metaclasses

26

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.

SystemEnvironment

Example Metaclasses

27

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.

Example Metaclasses

28

Physical Systems

• Examples of Physical Systems:– Toyota Camry Model XLE Automobile

– Caterpillar Model 3406 Diesel Engine

– Program Module 1750

– Part Number EC3445 Electronic Module

Example Metaclasses

30

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.

causal event 1

causal event 3

causal event 2

State C

State B

State A

Example Metaclasses

31

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.

causal event 1

causal event 3

causal event 2

State C

State B

State A

Example Metaclasses

32

Lawn mower exampleS ta rting

N orm a l M ow ing

S hu tting D ow n

S erv ic ing

O verhea t R ecove ring

law nm ow er s ta rted

shu t dow n in itia ted

ove rhea t recove ry com p le te

no rm a l shu t dow n com p le ted

se rv ice com p le te

s ta rt reques t rece ivedse rv ice reques t

rece ived

Law nm ow er S ta te

S hu t D ow n

Id ling

ove rhea ted shu tdow n com p le ted

d isengage m ow ing

engagem ow ing

Example Metaclasses

36

Function: Start Mower

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

EngineEngine

1: Request start2: Verify disengaged

3: Acknowledged

4: Start

5: Started

6: Signal running

OperatorOperator

ControllerController

Mower ClutchMower Clutch

Example Metaclasses

37

Functions describe “what” happens

• Systems describe “who” performs interactions.

• States describe “when” interactions occur.

• Functions describe “what” the interactions are.

Example Metaclasses

38

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.

Example Metaclasses

39

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.

Example Metaclasses

40

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 state1 and function modeling techniques

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

Example Metaclasses

41

Lawnmower example

Functions:1. Start (w/i 10 seconds of turning key) 2.Check Starting Interlocks (blades must be disengaged)3. Noise control (conform to ASPE 102.3 noise guidelines)4.Emission control (conform to EPA 11.2 emission guidelines)

Functions:1.Cut grass (to operator determined length)2. Noise control (conform to ASPE 102.3 noise guidelines)4.Emission control (conform to EPA 11.2 emission guidelines)

Functions:1. Disengage blades2. Shut down engine

Starting MowingShutting Down

Example Metaclasses

60

Class hierarchies and patterns

• Product evolution while maintaining corporate asset Corporate

Product Architecture

Family of Product Lines

Individual Configurations

SupportedHarvesting

benefits

Capturing new core value

Evolve Faster

Evolve Slower

• High leverage competitive configurability

61

Class hierarchies and patterns• Class hierarchies create patterns for all the metaclasses:

– systems

– states

– features

– functions

– interfaces

– views

– etc.

LawnmowerLawnmower

Rear engine riderRear engine rider

Self-propelled mowerSelf-propelled mower Tractor

Tractor

M 5Wide cut

self-propelled

M 5Wide cut

self-propelled

M 11Self-propelled

M 11Self-propelled

M17 Rear engine

rider

M17 Rear engine

rider

Push mowerPush mower

M 3Push mower

M 3Push mower

M 13Self-propelled

M 13Self-propelled

M 23Garden tractor

M 23Garden tractor

M 19Lawn tractor

M 19Lawn tractor

Walk-behind mowersWalk-behind mowers

Riding mowersRiding mowers

“is a type of”

62

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.

63

D ynam ic M ode l(FS M )

S ubc lass ing :T ra jec to ry andS ta te S p litting

M ost A bstract S uperc lassP rocess M ode l

M ore S pecific S ubclassP rocess M ode ls

E ven M ore S pecificS ubclass P rocess

M ode ls

Class Hierarchy of Dynam ic Process M odels (Finite State M achines)

AB

B1

B1

B2

B3

A1 A1

B1A B1B

A1A

A1A B1A

B1A

B2A

B2B

B2CB2DB3A

A1A

64

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

65

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

66

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.

67

Chapter Web Site Foundations of SE SIG PageFOUNDATIONS 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.

68

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

69

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.

70

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

Join our SIG! Thank you!

71

1. W. Schindel, “System Engineering: An Overview ofComplexity’s Impact”, SAE International, Technical Paper962177, October, 1996.

2. W. Schindel and G. Rogers, “Methodologies and ToolsSupporting Continuous Improvement”, to appear in: Journal ofUniversal Computer Science, March, 2000.

3. W. Schindel, “The Tower of Babel: Language and Meaning inSystem Engineering”, SAE International, Technical Paper973217, November, 1997.

4. Systems Engineering: The Journal of the International Councilon Systems Engineering—Special Issue on Capability MaturityModel Integration, John Wiley Publishers, March, 2002.

5. CMMI Tutorial, SEI, Carnegie Mellon University, Pittsburgh,PA, September, 2001, www.sei.cmu.edu/cmmi/publications/stc.presentations/tutorial.html

6. The web site of the International Council on SystemsEngineering: www.incose.org

7. “Processes for Engineering A System”, Electronics IndustriesAlliance (EIA), Publication ANSI/EIA-632-1998, January,1999.

8. “Systems Engineering Capability Model (SECM)”, ElectronicIndustries Alliance (EIA), Publication EIA/IS-731-1, January,1999.

9. “Systems Engineering Capability Model Appraisal Method(AM)”, Electronic Industries Alliance (EIA), PublicationEIA/IS-731-2, January, 1999.

10. Bate, Roger, et al, A Systems Engineering Capability MaturityModel, Version 1.1, Software Engineering Institute, CarnegieMellon University, Pittsburgh, PA, 1995.

11. Humphrey, Watts S., Managing the Software Process, AddisonWesley, New York, NY, 1989.

12. Humphrey, Watts S., A Discipline for Software Engineering,Addison Wesley, New York, NY, 1995.

13. Myers, Isabel Briggs, Gifts Differing, Consulting PsychologistsPress, Inc., Palo Alto, CA, 94303

14. Psychology of Programming, Hoc, J.-M., Green, T.R.G.,Samurcay, R., and Gilmore, D.,J., eds, Academic Press, Ltd.,London, U.K., 1990.

15. Arnheim, Rudolf, Visual Thinking, U. of California Press,Berkeley, CA, 1969.

16. Arnheim, Rudolf, Toward a Psychology of Art: CollectedEssays, U. of California Press, Berkeley, CA, 1966.

17. Arnheim, Rudolf, New Essays on the Psychology of Art, U. ofCalifornia Press, Berkeley, CA, 1986.

18. Hebb, Donald O., The Organization of Behavior, John Wiley &Sons Publishers, New York, NY, 1949.

19. James, William, The Principles of Psychology, Dover edition,Dover Publishing, New York, NY, 1980.

20. Hayakawa, S. I., Language In Thought And Action, fifthedition, Harcourt Brace Jovanovich, Publishers, Orlando, FL,1990.

21. Language, Thought, and Reality: The Selected Writings ofBenjamin Lee Whorf, J. B. Carroll, ed., MIT Press, Cambridge,MA, 1956.

22. Shastri, Lokendra, Semantic Networks: An EvidentialFormalization and its Connectionist Realization, MorganKaufmann Publishers, Los Altos, CA, 1988.

Bibliographic Sampler

72

Bibliographic Sampler23. Pinker, Steven, The Language Instinct: How the Mind Creates

Language, William Morrow and Co., New York, NY, 1994.

24. Chen, Peter, “The Entity-Relationship Model: Toward a UnifiedView of Data”, ACM Trans. On Database Systems 1, 1(March),9-36, 1976.

25. Booch, Grady, Object-Oriented Analysis and Design WithApplications, Second Edition, Benjamin Cummings Publishers,New York, NY, 1994 .

26. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen,W., Object Oriented Modeling and Design, Prentice-Hall, NewYork, NY, 1991.

27. Jacobson, I.,Christerson, M., Jonsson, P., Overgaard, G.,Object-Oriented Software Engineering: A Use-Case DrivenApproach, Addison-Wesley Publishers, New York, NY, 1993.

28. Alexander, Christopher, Notes on the Synthesis of Form,Harvard U. Press, Cambridge, MA, 1964.

29. Abelson, H., and Sussman, G., Structure and Interpretation ofComputer Programs, MIT Press, Cambridge, MA, 1985.

30. Morowitz, H., Energy Flow In Biology: Biological OrganizationAs A Problem In Thermal Physics, Ox Bow Press, Woodbridge,CT, 1979.

31. Prigogine, Ilya, From Being To Becoming: Time andComplexity In The Physical Sciences, W. H. Freeman Co., NewYork, NY, 1980.

32. The Principles of Organization In Organisms: Santa Fe InstituteStudies in the Sciences of Complexity, Vol XIII, Mittenthal, J.,and Baskin, A., eds., Addison-Wesley Publishers, Reading, MA,1992.

33. Glickstein, I. S., “Hierarchy Theory: Some Common Propertiesof Competitively-Selected Systems”, PhD. Thesis, State U. ofNew York at Binghamton, Systems Science Dept., Binghamton,NY, 1996.

34. Pattee, Howard H., ed., Hierarchy Theory: The Challenge ofComplex Systems, George Braziller Publishers, New York, NY,1973.

35. Alexander, Christopher, A Timeless Way of Building, Oxford U.Press, New York, NY, 1979

36. Alexander, Christopher, et al, A Pattern Language: Towns,Buildings, Construction, Oxford U. Press, Oxford, New York,NY, 1977.

37. Gamma, E., Helm, R., Johnson, R. , and Vlissides, J., DesignPatterns: Elements of Reusable Object-Oriented Software,Addison-Wesley, New York, NY, 1995.

38. Thompson, D’Arcy, On Growth and Form, Cambridge U. Press,Cambridge, UK, 1961.

39. Gerald M. Edelman, Topobiology: An Introduction to MolecularEmbryology, Basic Books, 1988.

40. Lawrence, Peter A., The Making of a Fly: The Genetics ofAnimal Design, Blackwell Scientific Publications, Oxford, U.K.,1992.

41. Wolpert, Lewis, The Triumph of the Embryo, Oxford U. Press,New York, NY, 1991.

42. Robert Rosen, Anticipatory Systems: Philosophical,Mathematical & Methodological Foundations, Pergamon Press,1985.

73

Bibliographic Sampler43. Ferguson, Eugene S., Engineering and the Mind’s Eye, MIT

Press, Cambridge, MA, 1992.

44. Miller, Arthur I., Imagery In Scientific Thought: CreatingTwentieth Century Physics, MIT Press, Cambridge, MA, 1986.

45. Arnheim, Rudolf, Entropy and Art: An Essay on Disorder andOrder, U. of California Press, Berkeley, CA, 1971.

46. Shaw, Mary and Garlan, David, Software Architecture:Perspectives On An Emerging Discipline, Prentice-HallPublishers, 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 FeInstitute 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: AComputer Model, MIT Press, Cambridge, MA, 1993.

52. Kosko, B., Neural Networks and Fuzzy Systems: A DynamicalSystems Approach to Machine Intelligence, Prentice-HallPublishers, Englewood Cliffs, NJ, 1993.

53. Rosalind L. Ibrahim, ed., Software Engineering Education,Eighth SEI CSEE Conference Proceedings, Springer Verlag,1995.

54. Edward Yourdon, Rise & Resurrection of the AmericanProgrammer, Prentice-Hall, 1996.

55. Boehm, Barry W., Software Engineering Economics, Prentice-Hall, New York, NY, 1981.