System Engineering:Structure of Complex System (Chapter 3) LECTURE OUTLINE:

3.1 3.2 3.2.1 3.3 3.3.1 3.3.2 3.4 3.4.1 3.4.2

Introduction to Structure of Complex System. Hierarchy of Complex Systems - Model of a Complex System. System Engineer vs. Design Specialist. System Building Blocks. Functional Building Blocks - Element. Physical Building Blocks - Element. The System Environment. System Boundaries. The Context Diagram.

3.4.2.1 Types of Environment Interaction.

3.1 INTRODUCTION TO STRUCTURE OF COMPLEX SYSTEM

The need for a systems engineer to attain a broad knowledge of the several interacting disciplines involved in the development of a complex system raises the question of how deep that understanding needs to be.

System engineer must recognize such factors as program risks, technological performance limits, and interfacing requirements, and make trade-off analyses among design alternatives. System building block provide an important insight by examining the structural hierarchy of modern systems.

3.2 HIERARCHY OF COMPLEX SYSTEMS - MODEL OF A COMPLEX SYSTEM

In order to understand the scope of systems engineering and what a systems engineer must learn to carry out the responsibilities involved in guiding the engineering of a complex system, it is necessary to define the general scope and structure of that system.

For the purpose of illustrating the typical scope of a systems engineers responsibilities, it is useful to create a more specific model of a typical system. Complex systems have a hierarchical structure (as illustrated in Figure 3.1) in that they consist of a number of major interacting elements.

Figure 3.0 System design hierarchy

System serves as parts of more complex aggregates or super-systems Subsystem- performs a closely related subset of the overall system functions (functional) Component- refer to a range of mostly lower level, middle of system level (physical) Parts- perform in combination with other parts.

3.2

SYSTEM

ENGINEER

vs.

DESIGN

SPECIALIST

Systems engineer knowledge needs to extend from the highest level, the system and its environment, down through the middle level of primary system building blocks or components. Design specialist knowledge needs to extend from the lowest level of parts up through the components level, at which point their two knowledge domains overlap. This is the level at which the systems engineer and the design specialist must communicate effectively, identify and discuss technical problems, and negotiate workable solutions that will not jeopardize either the system design process or the capabilities of the system as a whole. Figure 3.1 shows the knowledge domains of the systems engineer and the design specialist.

3.3 SYSTEM BUILDING BLOCKS

Using this system model provides systems engineers with a simple method of partitioning a system along a functional and physical dimension: understanding the functional aspects of the system, then partitioning the system into a physical hierarchy. Each dimensional description of the system can then be decomposed into elements.

3.3.1 FUNCTIONAL BUILDING BLOCKS - ELEMENTS Four classes of system functional elements:

Signal element: sense and communicate information (i.e., elements dealing with propagating information (e.g.,radiosignals)). Data element: interpret, organize, and manipulate information (i.e., those dealing with stationary information (e.g., computer programs)). Material element: provide structure and process materials. Energy element: provide energy and power

Thus, a television set, whose main function is to process information in the form of a radio frequency signal into information in the form of a TV picture and sound, is built of materials, powered by electricity, and controlled by user - generated information inputs. Accordingly, it should be expected that most elements in all classes would have information and energy inputs in addition to their principal processing inputs and outputs. The above process converges on a set of 23 functional elements, five or six in each class. These are listed in the middle column of Table 3.2. The function of the class as a whole is shown in the left column, and typical applications that might embody the individual elements are listed in the right column. It should be noted that the above classification is not meant to be absolute, but is established solely to provide a systematic and logical framework for discussing the properties of systems at the levels of importance to systems engineers.

3.3.2 PHYSICAL BUILDING BLOCKS - ELEMENTS

The classes into which the component building blocks have been categorized are based on the different design disciplines and technologies that they represent, such as in Table 3.2.

3.4

THE

SYSTEM

ENVIRONMENT

The system environment may be broadly defined as everything outside of the system that interacts with the system. The interactions of the system with its environment form the main substance of system requirements. Accordingly, it is important at the outset of system development to identify and specify in detail all of the ways in which the system and its environment interact. It is the particular responsibility of the systems engineer to understand not only what these interactions are but also their physical basis, to make sure that the system requirements accurately reflect the full range of operating conditions.

3.4.1

SYSTEM

BOUNDARIES

To identify the environment in which a new system operates, it is necessary to identify the systems boundaries precisely, that is, to define what is inside the system and what is outside.

Although defining the system boundary seems almost trivial at first glance, in practice, it is very difficult to identify what is part of the system and what is part of the environment. Many systems have failed due to miscalculations and assumptions about what is internal and what is external. Moreover, different organizations tend to define boundaries differently, even with similar systems. Fortunately, several criteria are available to assist in determining whether an entity should be defined as part of a system:

Developmental Control. Does the system developer have control over the entitys development? Can the developer influence the requirements of the entity, or are requirements defined outside of the developers sphere of influence? Is funding part of the developers budget, or is it controlled by another organization?

(who makes it?)

Operational Control. Once fielded, will the entity be under the operational control of the organization that controls the system? Will the tasks and missions performed by the entity be directed by the owner of the system? Will another organization have operational control at times? (who controls it?)

Functional Allocation. In the functional definition of the system, is the systems engineer allowed to allocate functions to the entity? (who decides what it can do?)

Unity of Purpose. Is the entity dedicated to the systems success? Once fielded, can the entity be removed without objection by another entity?

(does

it

has

the

same

goal

as

the

system?)

3.4.1 USER

ENTITY

In a majority of cases, the user or operator should be considered external to the system. The system developer and owner rarely have sufficient control over operators to justify their inclusion in the system. When operators are considered external to the system, the systems

engineer and the developer will focus on the operator interface, which is critical to complex systems. From another perspective, most systems cannot operate without the active participation of human operators exercising decision and control functions. In a functional sense, the operators may well be considered to be integral parts of the system. However, to the systems engineer, the operators constitute elements of the system environment and impose interface requirements that the system must be engineered to accommodate. Accordingly, in our definition, the operators will be considered to be external to the system. For example, a spacecraft must be launched from a complex gantry, which performs the fueling and flight preparation functions. The gantry, however, is usually a part of the launch complex and not a part of the spacecrafts development.

3.4.2

THE

CONTEXT

DIAGRAM

An important communications tool available to the systems engineer is the context diagram. This tool effectively displays the external entities and their interactions with the system and instantly allows the reader to identify those external entities. Figure 3.2 shows a generic context diagram.

The diagram consists of three components:

External Entities. These constitute all entities in which the system will interact. Many of these entities can be considered as sources for inputs into the system and destinations of outputs from the system.

Interactions. These represent the interactions between the external entities and the system and are represented by arrows. Arrowheads represent the direction or flow of a particular interaction.

The System.

Medium of interactions are:

Data Signals Materials Energy Activities

Figure 3.3 provides a simple example using a typical automobile as the system. Although the system is rather simple, it nicely illustrates all five types of interfaces. Four external entities are identified: users (to include the driver and passengers), the maintainer (which could be a user, but, because of his specialized interactions with the system, is listed separately), an energy source, and the environment. Most systems will interact with these four external entity types. Of course, many other entities may interact with a system as well. The user provides a multitude of inputs to the system, including various commands and controls as well as actions, such as steering and braking. Materials are also passed to the system: cargo. In return, several outputs are passed from the automobile back to the user, including various status indications on the state of the system. Additionally, an activity is performed: entertainment, representing the various forms of entertainment available in todays automobile. Finally, cargo is returned to the users when desired. Other entities also interact with the system. The maintainer must provide a request for diagnostics data, typically in the form of signals passed to the auto via an interface. Diagnostics data are returned along with the exchange of parts The last two external entities represent somewhat specialized entities: an energy source and the ubiquitous environment. In the automobile case, the energy source provides gasoline to the automobile. This energy source can be one of many types: a gasoline pump at a station or a small container with a simple nozzle. The environment requires some special consideration, if for no other reason than it includes everything not specifically contained in the other external entities. So, in some respects, the environment entity represents other. In our example, the automobile will generate heat and exhaust in its typical operation. Additionally, a siren and light from various light bulbs, horns, and signals will also radiate from the auto. The environment is also a source of many inputs, such as physical support, air resistance, and weather. So, how do we know whether an external entity should be included in our diagram? Fortunately, there is a simple answer to this: if the interaction is important for the design of the system, then it should be included. In our automobile case, physical support is important for our design and will influence the type of transmission, steering, and tires. So we include support in our diagram. Temperature, humidity, pressure, and so on, will be a factor, but we are not sure about their importance to design, so we group these characteristics under weather. This does not mean that the automobile will be designed for all environmental conditions, only that we are not considering all conditions in our design. We should have an idea of the environmental conditions from the requirements, and therefore, we can determine whether they should be in our context diagram.

Output from the system to the environment also depends on whether it will influence the design. The automobile will in fact output many things into the environment: heat, smells, texture, colors and especially carbon dioxide as part of the exhaust! But which of these influence our design? Four will be major influences: heat, noise from the siren, exhaust, and light. Therefore, we include only those for now and omit the others. We can always go back and update the context diagram (in fact, we should, as we progress through both the systems engineering process and the system development life cycle). All in all, the system context diagram is a very simple yet powerful tool to identify, evaluate, and communicate the boundaries of our system.

3.4.2.1 TYPES OF ENVIRONMENTAL INTERACTION

Types of environmental interactions are:

Inputs and Outputs: The primary purpose of most systems is to operate on external stimuli and/or materials in such a manner as to process these inputs in a useful way. For a passenger aircraft, the materials are the passengers, their luggage, and fuel, and the aircrafts function is to transport the passengers and their belongings to a distant destination rapidly, safely, and comfortably. System Operators: As noted previously, virtually all systems, including automated systems, do not operate autonomously but are controlled to some degree by human operators in performing their function. For the purposes of defining the systems engineers task, the operator is part of the systems environment. The interface between the operator and the system (human machine interface) is one of the most critical of all because of the intimate relationship between the control exercised by the operator and the performance of the system. It is also one of the most complex to define and test Operational Maintenance: The requirements for system readiness and operational reliability relate directly to the manner in which it is to be maintained during its operating life. This requires that the system be designed to provide access for monitoring, testing, and repair requirements that are frequently not obvious at the outset, but nevertheless must be addressed early in the development process. Thus, it is necessary to recognize and explicitly provide for the maintenance environment. Threats: This class of external entities can be man - made or natural. Clearly, weather could be considered a threat to a system exposed to the elements. For example, when engineering naval systems, the salt water environment becomes a corrosive element that must be taken into consideration. Threats can also be man - made. For example, a

major threat to an automatic teller machine (ATM) would be the thief, whose goal might be access to the stored cash. System threats need to be identified early to design countermeasures into the system.

Support Systems: Support systems are that part of the infrastructure on which the system depends for carrying out its mission. The airport, the air traffic control system, and their associated facilities constitute the infrastructure in which an individual aircraft operates, but which is also available to other aircraft. System Housing: Most stationary systems are installed in an operating site, which itself imposes compatibility constraints on the system. In some cases, the installation site provides protection for the system from the elements, such as variations in temperature, humidity, and other external factors. In other cases, such as installations on board ship, these platforms provide the systems mechanical mounting but, otherwise, may expose the system to the elements, as well as subject it to shock, vibration, and other rigors. Shipping and Handling Environment: Many systems require transport from the manufacturing site to the operating site, which imposes special conditions for which the system must be designed.