Model-Based Systems Engineering

A. Wayne Wymore

• Publisher: CRC Press
• Year: 2018
• ISBN:
  9781351431088
• Edition: 1
• Topic: Technology & Engineering
• Subtopic: Engineering General
• Index: Technology & Engineering

Model-Based Systems Engineering explains the fundamental theories behind model-based systems and the considerations involved in applying theory to the design of real systems. The book begins by presenting terms used in systems engineering and introducing the discrete system and its components. The remainder of the text explains topics such as the mathematical theory of system coupling, the homomorphic relationship between systems, the concept of system mode, the mathematical structure of T3SD system requirements, and the implications of that structure for T3SD system design. Appendices include a short bibliography, detailed definitions of all examples discussed in the text, a list of all notations used, and an index.
Model-Based Systems Engineering is an excellent text for engineering students, and an invaluable reference for engineers and scientists.

chapter one

Systems engineering

Introduction

1.1 The purpose of this chapter is to motivate the mathematical theory developed in the rest of the book; the purpose of the mathematical theory is to support the systems engineering process described in this chapter.

Before the definition of systems engineering is given, it is appropriate to discuss what systems engineering is not. Here is a short list of disciplines that systems engineering is not: applied mathematics, applied probability and statistics, economics, operations research, computer science, numerical analysis, simulation, system theory, system science, human factors engineering, software engineering, agricultural engineering, civil engineering, electrical engineering, industrial engineering, manufacturing engineering, mechanical engineering.

It has even been said that systems engineering is just good “blank” engineering, where the “blank” can be filled by any engineering descriptor whatever. “Blank” engineers ought to use the tools of systems engineering in their work and many do. It is rare, however, when “blank” engineers develop the intellectual tools to do a good job of systems engineering even in the very restricted field in which they are experienced, and almost never are “blank system” engineers able to apply their skills effectively in any other field. “Blank system” engineers are successful when they do not stray too far from the physical principles of their basic disciplines. It will become apparent, however, that systems engineering must start “above” the level of physics.

Some have insisted that systems engineering is management. This is partly true, but systems engineering is more than management. Systems engineering, like any other human cooperative activity, must be managed, but nobody ever designed a good system by management without people who were skilled at the technical work of systems engineering.

Each discipline in the preceding list deals with some aspect or aspects of systems engineering and systems engineering uses most of the tools represented in the above list, yet systems engineering is not the sum of the disciplines in the list. If one were to ask practitioners of any discipline in the preceding list, they would characterize themselves as problem-solvers. Systems engineers, in contrast, are problem staters.

The principal functions of systems engineering are:

• to develop statements of system problems comprehensively, without disastrous oversimplification, precisely without confusing ambiguities, without confusing ends and means, without eliminating the ideal in favor of the merely practical, without confounding the abstract and the concrete, without reference to any particular solutions or methods,

• to resolve top-level system problems into simpler problems that are solvable by technology: hardware, software, and bioware,

• to integrate the solutions to the simpler problems into systems to solve the top-level problem.

By performing these functions, systems engineering becomes a bridge between the system problems generated by society and the solutions provided by technology.

Systems engineering had to be invented because these functions have not been properly performed. Why are the functions of systems engineering so difficult to perform? The culprit lies in technical education. Everyone is taught to think in terms of solutions. Ask any person what he or she thinks about a current national problem; energy, juvenile delinquency, drugs—almost any problem will do for this test. That person will “know” or at least have an opinion about “the solution” to the problem. And the “better” educated we are, the more confident we will be that our solution is the “correct” one. Rarely will a person be found who will suggest that the problem is not well-understood and that more resources should be invested in stating the problem before a “solution” is implemented.

This orientation toward thinking about problems in terms of solutions begins even in the elementary grades, where the pupils are discouraged from asking questions about the problems or questions posed to them. The teacher rewards only “the answer.” Pupils who question the problem statement are immediately banished to the “lunatic” fringe.

Later on, in technical education, the student is given explicit techniques to solve relatively simple problems: Consider a spherical elephant(!)…and then assigned exercises in utilizing this technique on equally unrealistic problems. The students emerge from this educational experience as professionals with tool box mentalities, each one a Mr. Wrong Wrench going about the world looking for problems that they can solve with the tools in their tool boxes and, unfortunately, thinking that they find them or, at least, applying their tools willy-nilly, rarely even conscious that these tools were developed for problems much simpler than the one at hand!

This tool-box mentality also explains, to an extent, the constant pursuit of and devotion to trendy new “solutions” to problems, such as statistics, information theory, cybernetics, operations research, control engineering, biofeedback, computers, simulation, CIX (computer integrated anything), expert or knowledge-based systems. Each of these fields was heralded, by some, as the source of solutions to all problems; all of them have taken their appropriate and honorable places in the intellectual arsenal, but none have lived up to all the promises made for them. The reason is that not all problems can be stated in terms of a solution or class of solutions.

Another culprit in education is mathematics. Here the student is taught to simplify problems as a technique for solving them. This is all right for problems involving relatively simple equations where the simplification procedures lead to perfectly equivalent problems. Blind simplification of large-scale, complex system problems, however, almost always leads to disaster, because simplification procedures almost never lead to equivalent problems! This is one reason that it is so important to characterize the set of all design solutions to a system design problem.

There is no discipline (except systems engineering) that teaches students how to state problems comprehensively, without disastrous oversimplification, precisely without confusing ambiguities, without confusing ends and means, without eliminating the ideal in favor of the merely practical, without confounding the abstract and the concrete, and without reference to any particular solutions or methods.

In the absence of such a problem statement, methodological errors are frequently perpetrated. For example,

• Attempts are made to put together solutions to simple problems hoping to solve a larger, though unstated, problem. The system is built from the bottom up: tying together islands of automation, etc.

• A solution to an imprecisely stated problem is visualized and then the implementation of that vision becomes the problem! This happens frequently in industry and government as a result of “macho” or “political” engineering. Basically, the error is to state the problem in terms of a “solution.” If a system design problem has been stated only sketchily or hardly at all, then any system that is built will constitute a solution. Is this the reason that system design problems are not stated precisely and comprehensively: the fear that if the system design problem is stated precisely and comprehensively, then a favorite design might not be a solution? Or is it merely the innocent, but incorrect, perception that there is not enough time or other resources to do the job right?

• A system is designed and built, but it turns out that it does not solve the real problem because the real problem was never stated. Then the real system itself becomes a real problem: to modify the real system so that it really does solve the original problem. Frequently, this retrofitting must be accomplished by the users of the system at great expense.

• Executives look first for technology to solve their problem before the problem is stated. To design a system, they call in the hardware and software vendors to see what they have that will “solve” their problem. This strategy will be employed by people who wouldn’t dream of trying to build a building without an architect but will pay millions for hardware and software that will not solve the real problem. They wouldn’t ask the plumbers, bricklayers, and electricians to design the buildings, but they would ask the hardware and software vendors (ignoring human factors) to design their systems!

• The wrong people are assigned (or take it upon themselves) to design systems. Truck drivers cannot design trucks; no pilot would fly in an airplane designed entirely by airline pilots. Judges are not qualified to design systems for racial integration of schools. Physicians do not have the training to design health care delivery systems. Generally, a person cannot, and should not, design a system of which he or she is a component. Input of human components of systems is crucial to the design process for generating requirements, but rarely for designing systems.

• Private and public foundations issue grants to support “applied” research that neither science nor society knows how to “apply.” There is certainly a place for pure science, but much research should be done within the context of an overall system design so that when the research is finished society and science know where it will fit and can be used.

• Systems are designed and built to solve overly simplified problems and thus create more problems than they solve.

• Systems are designed and built to solve problems, and society then finds that the system proponents cannot prove that they have accomplished anything! This seems to be especially true for social systems.

• Acquisition of large-scale, complex systems seems typically to involve huge cost and schedule overruns and disastrous performance shortfalls.

How can these methodological errors be avoided? These errors can be avoided or vastly ameliorated through the process of systems engineering carried out by well-trained systems engineers. What, then, is the systems engineering process? The definition of the systems engineering process has the following objectives:

• to incorporate the total system point of view,

• to incorporate the p...