Michael Larsen’s Kindle Notes & Highlights for Model-Based Systems Engineering

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.

2%

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.

2%

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

2%

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

2%

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

This highlight has been truncated due to consecutive passage length restrictions.

2%

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

This highlight has been truncated due to consecutive passage length restrictions.

2%

to incorporate the total system point of view, • to incorporate the point of view that systems exist to serve human needs, • to incorporate the system life-cycle point of view, • to apply to the design of personnel/machine/software systems in any functional or technological context, • to be independent of but adaptable to any customer, • to be couched in informal and intuitive terms but to constitute the basis for mathematical definitions, • to provide the basis for professional education and activity, and • to clarify the concepts of system design and system analysis and the relationship of ...more

2%

systems engineering efforts: accounting, agricultural information, agricultural water quality, air pollution control, air traffic control, aircraft, antisubmarine, architectural, automobile, ballistic missile defense, biological control, communication, computer, construction, day-care, distributed computer, earthquake warning, ecological management, education, emergency medical, energy production and distribution, equal opportunity, expert, farming, fire protection, food production and distribution, garbage recycling, health delivery, housing, information, inventory, juvenile delinquency ...more

This highlight has been truncated due to consecutive passage length restrictions.

2%

What is the system supposed to do? What is it supposed to accomplish? What inputs must be processed and what outputs produced? What is the essence of the system in technology-free terms? • What is available to build the system? Are there restrictions on what must be used or what can be used? • How well must the system do whatever it is that the system is supposed to do? By what criteria is the performance of the system to be judged? • What are the criteria for judging how well available resources have been used in building and operating the system? What are the cost requirements for the ...more

2%

performance requirements, cost requirements,

3%

(i) input/output requirements, (ii) technology requirements, (iii) performance requirements, (iv) cost requirements, (v) trade-off requirements, and (vi) system test requirements

3%

Input/output requirements

3%

1.10 Definition: A trajectory is any function of time. An input trajectory is a schedule or a time record of the way in which inputs can (do, will, might, ought to) arrive at the input ports of a system. An input trajectory can be thought of as a history of the input experience of a system. An output trajectory is a schedule or time record

3%

of the outputs produced by a system at its output ports over a period of time.

3%

Definition: The input/output requirement for a system to be designed consists of specifications of (i) the length of the operational life of the system to be designed, that is, the length of the operations phase of the system life cycle: see 1.53 and 1.105 (this sets a standard time scale for all input and output trajectories), (ii) the set of inputs to be accepted by the system to be designed, (iii) the set of input trajectories or histories which the system to be designed might experience, (iv) the set of outputs producible by the system to be designed, (v) the set of output ...more

3%

and (vi) the eligibility function that matches outputs and inputs or input trajectories and eligible output trajectories; the eligibility function limits, or specifies, the behavior of the system to be designed.

3%

Definition: A functional system design is a system design that satisfies the input/output requirement.

3%

1.13 Cotyledons: The

3%

tricotyledon theory of system

3%

Technology requirements

3%

logical design. The functional system design satisfies

What is the difference between a logical model and a functional model

3%

1.16 Definition: The technology requirement for a system to be designed consists of the specification of the set of components—hardware, software, and human or bioware—considered, by the designers and the customer, to be available to build the system to be designed.

3%

1.17 Definition: A buildable system design is a design specifying the system that results from

3%

The set of all buildable system designs is also called the space of buildable system designs or the buildability cotyledon.

3%

Performance requirements

3%

Definition: The performance requirement for a system to be designed is an algorithm by means of which any two functional system designs can be compared consistently with respect to how well each satisfies the input/output requirement

3%

Cost requirements

3%

For every buildable system design, it must be possible to compute or to estimate the value of such figures of merit.

3%

implementable system design.

3%

Trade-off requirements

3%

Definition: The trade-off requirement for a system to be designed consists of an algorithm by means of which any two implementable system designs can be compared consistently with respect to a trade-off between the performance and cost requirements.

4%

The tradeoff requirement is usually defined in terms of performance, cost, and trade-off figures of merit and their thresholds.

4%

1.39 The system test situation:

4%

1.40 Definition: An implementable test item

4%

Observance: How the real system shall be observed, sampled, measured, stimulated, simulated, and so forth, in order to estimate a value for each performance, cost, and trade-off figure of merit. The set of estimates of the values of all these figures of merit is called the test data. • Conformance: How it shall be proved, in terms

4%

of the test data, that the real system is in conformance with the implementable system design from which it was built. • Compliance: How it shall be proved, in terms of the test data, that the real system is in compliance with the system requirements.

4%

Acceptance: How it shall be proved, in terms of the test data, that the real system is acceptable to the customer

4%

Observance, conformance, compliance, and acceptance:

4%

observance specification.

4%

compliance specification.

4%

For each possible implementable test item, the system test requirement specifies, in terms of the test data, how to determine the conformance of the real system to the implementable system design on the basis of which the real system was built. This is called the conformance specification.

4%

acceptance specification.

4%

Typically, the criteria for acceptance of the real system to the customer will include the necessity for compliance with the requirements and conformance to the implementable system design,

4%

Definition: System design: To design a system is to develop a model on the basis of which a real system can be built, developed, or deployed that will satisfy all its requirements†.

4%

Many types of models of the system to be designed may be developed, for example, functional system designs (see the definition at 1.12), on the basis of which a system could not be built because they do not contain enough physical details. These may still be called system designs because they are necessary parts of or

4%

steps toward a system design on the basis of which a system could be built. Thus, the process of system design is not finished until a model has been developed on the basis of which a real system could be built, but many “designs” may have to be developed during the process.

4%

1.46 Definition: System analysis: To analyze a system is to develop a model by means of which a real system will be managed, controlled, augmented, evaluated, or modified in order to satisfy all its requirements.

4%

a sense, the work involved in the processes of system design and system analysis can be completely characterized as the creation and manipulation of models.

4%

Familiar example of modeling: The best known modeling context is linear regression wherein the set of models is the set of equations of the form Y = A * X + B where A and B are any real numbers. A set of data of the form (XI, Y1),…,(XN, YN) is modeled in this set of models by choosing A and B according to the following criterion: the sum of squares of deviations is minimized.

4%

System theoretic models are developed, manipulated, and managed by systems engineers throughout the life cycle of any large-scale, complex, bioware/hardware/software system.