Does Our SE House Have a Foundation

1. Does Our SE House Have a Foundation? For the next 40 minutes I�m going to introduce you to the basic concepts we use in the SE Methodology. After that I will show you how we combine it all to develop High Level Requirements Specifications for Systems.For the next 40 minutes I�m going to introduce you to the basic concepts we use in the SE Methodology. After that I will show you how we combine it all to develop High Level Requirements Specifications for Systems.

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?

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

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

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?

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?

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?

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?

10. Examples of SE foundation concepts Metaclasses Systems States Functions Features Interfaces, Systems of Access, Boundaries Views

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

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

14. The Man-Made World Is Increasingly Populated by Systems Transportation, Energy & Power Systems Manufacturing, Construction Systems Telecommunication Networks Man-Made Biological & Health Care Systems Facility, Properties Business Processes Other Man-Made and Natural Systems

15. These Systems Are Becoming More Complex Under pressure of demand & competition Enabled by progress in technology Becoming more complex at exponentially growing rates

16. The Growth Of Systems Complexity Eventually Can Outpace Human Ability To: Describe Predict Manage Monitor Configure Evolve

17. . . . At Least Within Reasonable: Time Cost Effort Sense of Security from Risk

18. The System Metaclass

19. Systems may be any technology Mechanical Electronic Software Chemical Thermodynamic Human organizations Biological

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.

21. Example system System: Semi-trailer truck hauling freight Components: engine, power train, suspension, lubrication system, fuel system, braking system, electrical system, cab, trailer, navigation system, communication system, software modules Relationships: physical containment, power dependency, control interaction, mechanical connection, thermal interaction

22. Example system System: Telecommunication services system Components: telephones, modems, workstations, transmission links, circuits, switches, base stations, communication sessions, software, customer requests, billing systems, customer analysts Relationships: electrical & optical connection, electromagnetic signaling, physical containment, power dependency, fault dependency, session usage

23. Containment Hierarchy: Subsystems

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.

25. Logical Systems Logical Systems are typically named and defined without reference to proper names such as product names. They are typically defined without reference to their physical composition, unless (in some cases) this is a part of the external behavior description.

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.

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.

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

29. Physical and Logical Systems A Logical System is equivalent to a functional role. Physical Systems may be assigned responsibilities to perform roles that are Logical Systems. What plays the role of Engine System in a gas-fired generator? What plays the role of Engine System in a hybrid automobile?

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.

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.

32. Lawn mower example Here�s a specific one for a LM.Here�s a specific one for a LM.

33. Naming and defining states States have names and definitions: State name: a brief verb phrase, usually in �-ing� form State definition: one or a few sentences Example: State name: Idling State definition: The lawnmower motor is running at a minimum speed necessary to support sustained combustion, but not for performance of work against an external load.

34. Concurrent states When two states are part of a single connected graph (state machine) in a state transition diagram, they can only occur at different times. When two states in a state transition diagram are not part of the same connected graph (state machine), then they can occur at the same time, and are called concurrent states. States B and D below are concurrent, and can therefore be simultaneous. States A and B can never occur at the same time.

35. Containment hierarchies of states States can be decomposed into sub-states and arranged in state containment hierarchies. Sub-states are drawn inside their parent states in a state transition diagram. A sub-state can occur only when its parent state is occurring.

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

37. Functions describe �what� happens Systems describe �who� performs interactions. States describe �when� interactions occur. Functions describe �what� the interactions are.

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.

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.

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.

41. Lawnmower example

42. Diesel engine control example

43. Functions are bigger than roles If we only wanted to describe what one system is supposed to do, we only need to describe its role, not the roles of the other actors in the function. So, why did we describe a whole function (interaction between blocks) instead of just a role (what one block does)?

44. Functions are bigger than roles Answer: One of the central problems of system engineering is the coordination of work across organizations so that different subsystems can be integrated successfully. (System integration.) There are countless �war stories� of subsystems that did not integrate together as smoothly as expected. In this methodology, we treat the overall collaborations (functions) as fundamental, so that we begin with the integrated result sought and track it throughout the process. We will still model what single subsystem blocks do (roles), but we will keep track of how those roles fit into integrated collaborations (functions) from the outset.

45. Negotiation: At the Heart of System Integration

46. Function roles are logical systems Remember the definition of logical system? �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.� This means that individual functional roles are exactly the same thing as logical systems. Logical systems and functional roles are just different names emphasizing different aspects of the same idea (�being� versus �doing�).

47. Function roles are allocated to systems Remember the allocation of logical roles to physical systems? �Physical Systems may be assigned responsibilities to perform roles that are Logical Systems.� Example: Function = Manage Engine Speed Roles = Engine Speed Controller, Managed Engine Allocation: Engine Speed Controller is allocated to Engine ECM A role can be allocated to several physical design components: Allocation: Engine Speed Controller is allocated to Engine ECM (hardware), Engine Speed Control Module (software), ECM Input Circuit 14 (input circuit assigned to speed sensor), and ECM Output Circuits 26-34 (output circuits assigned to fuel injection)

48. Function roles are allocated to systems Logical roles can also be allocated to larger logical systems Example: Function = Manage Engine Speed Roles = Engine Speed Controller, Managed Engine Allocation: Engine Speed Controller is allocated to Engine Manager, a larger logical system This larger logical system may in turn be allocated to a physical system (such as Engine ECM).

49. Interaction Diagrams Interaction diagrams illustrate functional interactions graphically. Two common styles of interaction diagram: Sequence Diagram (aka Timing Diagram) Illustrates interactions organized on a timeline Collaboration Diagram (aka Block Diagram) Illustrates interactions between blocks, not necessarily in time sequence Interaction diagrams are central to effectively documenting and communicating functions.

50. Interaction Diagram: Sequence Diagram Style

51. Interaction Diagram: Collaboration Diagram Style

52. The View Component Metaclass Informal Definition: A View Component is the information or physical quantity exchanged between interacting systems. Formal Definition: In a functional interaction of systems through a system of access, a View Component is the state of the system of access used to describe how the states of the interacting systems are impacted. In a diagram representing the interaction, a view component is referenced as a view component name on an interaction line.

53. View Components View Component names are shown on interaction lines in sequence diagrams or collaboration diagrams.

54. Decomposing Functions Functions can be decomposed into function containment hierarchies; e.g.- Manage Engine Speed Sense Throttle Position Read Throttle PWM Sensor Sense Engine Speed Perform Engine Speed-Timing Sensing Perform Engine Speed Control Loop Control Engine Fueling Transmit Injector Command The smaller functions are said to be �contained� in the larger functions, and are called sub-functions. This is functional decomposition.

55. Decomposing Functions: Notation and Diagrams Sub-functions are sometimes labeled with their name plus that of their parent, separated by a period: Start Mower.Crank Engine

56. The Feature Metaclass A feature is collection of functions having marketable value. Features versus functions: The feature�s collection of functions is what makes the feature work. Features summarize functions to customers and users, in value packages. Features are the reasons customers buy systems. Prices are often associated with features. Features are the reasons users use systems. Features are where customers and marketing organizations live. Functions are where engineers and designers live. Features provide a traceable linkage between summary market value specifications and detailed engineering specifications, so that nothing gets lost between these two worlds.

57. Examples of Electronically Defined Features Vehicle Cruise Control Feature Automatic Breaking Feature Traction Control Feature Passenger Temperature Control Feature Fault Warning Feature Electronic Service Tool Diagnostics Feature

58. Services Features are also known as Services in some domains. Particularly when they are subject to measurement and formal agreements.

59. Services A Service is: a feature of a system what system users consume something that can be measured and be subject to a service level agreement

60. Class hierarchies and patterns Product evolution while maintaining corporate asset The ICTT System Engineering Methodology will help you manage complexity Move beyond basic SE level practices (that address only single product instance) into something we call SE Level 2: Managing complexity.The ICTT System Engineering Methodology will help you manage complexity Move beyond basic SE level practices (that address only single product instance) into something we call SE Level 2: Managing complexity.

61. Class hierarchies and patterns Class hierarchies create patterns for all the metaclasses: systems states features functions interfaces views etc.

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. In addition to class hierarchies of UC�s you can also have class hierarchies of FSM�sIn addition to class hierarchies of UC�s you can also have class hierarchies of FSM�s

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 Page

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.

71. Bibliographic Sampler

72. Bibliographic Sampler

73. Bibliographic Sampler