Systems engineering techniques, tools, and procedures

print Print
Please select which sections you would like to print:
verifiedCite
While every effort has been made to follow citation style rules, there may be some discrepancies. Please refer to the appropriate style manual or other sources if you have any questions.
Select Citation Style
Share
Share to social media
URL
https://mainten.top/topic/systems-engineering
Feedback
Corrections? Updates? Omissions? Let us know if you have suggestions to improve this article (requires login).
Thank you for your feedback

Our editors will review what you’ve submitted and determine whether to revise the article.

If a system is both large and complex in the sense in which these terms have been defined, it may be difficult to find out how it works. A large part of the content of systems engineering consists of techniques for the investigation of such relatively complex situations.

Modeling and optimization

Perhaps the most fundamental technique is the flow diagram, or flowchart, a graphical display composed of boxes representing individual components or subsystems of the complete system, plus arrows from box to box to show how the subsystems interact. Though such a representation is very useful in an initial study, it is, of course, essentially qualitative. A more effective approach in the long run is construction of a so-called mathematical model, which consists of a set of equations, or sometimes simply of tables and curves, describing the interactions within the system in quantitative terms. It is not necessary for the mathematical model to be exact, as long as it serves its purpose. It frequently consists of piecewise linear approximations to basically nonlinear situations (i.e., a series of short straight lines that roughly approximate a curve). After the model has been constructed and checked, a number of mathematical techniques can be employed (including straightforward enumeration and computing) to find out what it says about the actual operation of the system. Often these calculations will have a probabilistic or statistical flavour.

When the components or subsystems interact significantly, it may be possible to achieve essentially the same final level of performance in many different ways. Limited performance by one subsystem may be offset by superior performance somewhere else. These optimization studies, called trade-offs, are important in suggesting how to achieve a given result in the most economical manner. They are equally valuable in suggesting whether or not the proposed result is in fact a reasonable goal to aim for. It may be found, for example, that a modest reduction in performance will permit radical savings in overall cost or, conversely, that the postulated equipment is capable of much better performance than is asked of it, at only nominally greater expense. (It may also turn out that the equipment can supply useful functions not originally contemplated. Computing systems, for example, can usually perform extra chores of record keeping at little increased cost.) For all of these reasons, studies of such variables are an important part of systems engineering, both in the early exploratory phases of a project and in the final design.

Identifying objectives

The formulation of suitable objectives for the final system is so important a part of the systems engineering process that it deserves special attention. It is, of course, always possible to state the general objectives of a system in vague or perfectionist terms. A sufficiently clear, precise, and comprehensive statement to serve as a basis for engineering studies, however, is another matter. Unless the situation has been well explored in the past, the real choices are not likely to be obvious when the work begins. Thus, the first task of the systems engineer is to develop as clear a formulation of objectives as possible. This usually involves computations and consultation with others interested in the system. Because the final statement must reflect value judgments as well as purely technical considerations, the systems engineer does not try to do this thinking alone but attempts to serve as a working focus and catalyst. Although issues of this sort naturally present themselves with particular force near the beginning of a systems study, they may recur in subsequent steps. The question of objectives is never really out of the systems engineer’s mind.

The principal reason why a satisfactory statement of objectives may present such a problem is simply that most systems have multiple objectives, often in conflict with one another. In the design of transport aircraft, for example, there are a multitude of desirable characteristics, such as range, speed, payload, and safety, to be maximized, as well as undesirable characteristics, such as noise generation and air pollution, to be minimized. Because the same design cannot do the best job in all of these directions, a compromise achieving the most desirable overall performance is required. The most attractive compromise, which may require both study and ingenuity, is not likely to be found at all until some hard thinking has been done about what characteristics are really needed.

Especially difficult problems in defining objectives may arise when an existing technology is transplanted to some new disciplinary area. An example is the application of electronics such as computer techniques to medicine and education. It seldom happens in such cases that the best system is based on a simple one-for-one substitution, such as direct replacement of a classroom teacher by electronic hardware and computer-assisted instruction materials. It is much more likely that the most effective plan will turn out to be a rather complicated mixture of the old and the new. This conclusion, however, is likely to raise basic issues about the actual objectives of the new system, issues made no simpler by the interdisciplinary nature of the situation.

A design example

The design of the commercial transport plane mentioned above is an example of a systems engineering problem. In such a design the aerodynamic lift, the drag of fuselage and wings, the control apparatus, the propulsion system, and such auxiliary hardware as the landing gear all interact substantially. One element cannot be disturbed without affecting the others; all elements and aspects of the total system, and the interactions among them, must be considered. Thus, if designers make the fuselage fatter and the wings smaller in an effort to carry more payload at the same or higher speeds, a new control system might be needed because of the changes produced in the overall mechanical and aerodynamic characteristics of the vehicle. Stronger and heavier landing gear might be needed to withstand higher landing speeds. Almost surely, the new design would call for larger engines and fuel tanks to compensate for greater aerodynamic drag. Thus the designers would have lost ground in some respects and gained in others. The new plane might be more useful for short flights when not much fuel must be carried but less useful for long ones. Obviously, the system objective—the kind of airplane actually wanted—must control the direction of any such study.

The study becomes more interesting if a possible advance in basic technology is considered, such as an improvement in propulsion or aerodynamics, and it is desired to determine how it might best be applied in a new airplane design. The central systems engineering question then would probably encompass the relation between the available new plane characteristics and the needs of the existing air transportation system. Clearly, such an investigation can be made only by going to one of the upper levels in the systems hierarchy.

Finally, to operate the new airplane successfully, a whole series of supporting functions may be required, including routine checkout, maintenance, and spare parts supply, in addition to functions directly involved in the plane’s flight. Though, under normal circumstances, these might readily be handled by the existing operating staff, it is part of the user orientation of the systems approach that the systems engineer is expected to anticipate any new requirements and make sure they are properly planned for.

To make adequate comparisons between competing objectives, a logical frame of reference, broad enough to include both, is needed. Thus, the systems engineer may study many situations in the framework of more than one system or a whole hierarchy of systems of steadily increasing generality. In the example of an airplane, the airplane itself is a possible system, as are the group of planes owned by one airline, the total number of airplanes in a particular country, and that nation’s transportation facilities. Though the simplest system—the airplane itself—is a satisfactory reference for specific design problems, a more general framework may be needed to approach broader problems. Thus the individual airplane designer may seek to ameliorate air-traffic congestion by improving airplane takeoff and landing characteristics, permitting better utilization of existing airports. The airlines in turn may suggest construction of more and better airports. From the point of view of the transportation system as a whole, the best step might be to invest more money in high-speed rail facilities to carry part of the air-traffic load. In systems engineering the error of studying the problem within too narrow a framework is called the error of suboptimization.

User orientation

The stress on systems objectives has one further consequence worth mentioning; i.e., that systems engineering is likely to be strongly user-oriented. This results naturally enough from the fact that systems objectives usually relate to overall performance, which is what the final user is interested in. The identity of technical interest between the systems engineer and the final user is usually marked; systems engineering is likely to give special consideration to such qualities as reliability, ease of maintenance, and convenience in operation. Moreover, the final step of a systems engineering project is typically an evaluation that attempts to find out how well the system works in the hands of the user.

Tools

The most obvious aspect of systems engineering tools is their great diversity. A leading text in the field states that “there is virtually no scientific discipline which may not be used in the design of some large-scale system” and singles out probability, mathematical statistics, computing, system logic, queuing theory, game theory, linear programming, cybernetics, group dynamics, simulation, information theory, servomechanism theory, and human engineering. To this list might also be added decision theory, nonlinear programming, some elements of econometrics, and communications theory as related to random processes.

In spite of this diversity, many of the tools of systems theory can be grouped under a few major headings. The analytic problems associated with optimization, for example, are a recurrent theme. Probability and statistics are also major areas that carry with them numerous more specialized topics, such as queuing theory and much of communications theory. Finally, computing is a major field for the systems engineer. If all else fails, direct calculation or simulation may produce the desired results.

These fields are all essentially mathematical in nature. The systems engineer may need knowledge and skills of other sorts as well. The mathematical model and associated objective functions that conventionally begin a systems analysis, for example, are only satisfactory to the extent that they adequately represent the real physical situation. The adequacy of a mathematical model in this sense, however, is a matter of physical or engineering rather than mathematical judgment. In some circumstances the systems engineer may also need to know something about experimental procedures in general and, in particular, about ways of maximizing the amount of information from a given testing program. This is particularly likely to happen in urgent high-risk projects, like space exploration or nuclear power generation, in which intermediate testing failures are bound to occur, and the systems engineer, as part of his overall responsibility, must decide what to do next. Even in simpler cases, in which the project should close in a final test and evaluation phase, the systems engineer is responsible for ensuring that this work is adequately carried out. A closely related question is the monitoring of testing procedures for routine quality control purposes. This also is logically part of the systems engineer’s duties, which reflect a basic user orientation. When reliability is very important, as in space programs, it may be a major responsibility.

When the systems engineer’s job is defined as including significant management responsibility, some acquaintance with modern management techniques is an obvious requirement. The techniques of particular importance are those that bear most directly on cost figuring and scheduling technological developments.

Finally, systems engineering is used in new situations that may involve the application of new discoveries in science or technology to existing technical areas or the application of known science or technology in new contexts. In either case the systems engineer obviously needs considerable substantive knowledge of the fields involved in order to make reliable plans.

It is apparent that no single person is likely to meet all of these specialized qualifications. Thus, systems engineering on any significant scale almost invariably involves a team approach.