chapter 4 syse

Center of Gravity Model for Facility location Planning

The center of gravity method uses a map to show all the destination loca-tions. Using an (x, y) coordinate system, each of the destination locations can be identified on the map, There are many models for location planning; selection of the model depends on the different objectives and constraints in which the planning is involved. Here we introduce a model called the center of gravity method. It is widely used in operations management to find the location of a facility that minimizes total travel time or costs to various destinations.

what is the output of system functional modeling

The output of the system functional modeling is development of a com-plete list of (1) systems functions and their hierarchical structure and (2) the interrelationships between system functions at different hierarchical levels, represented by the functional flow block diagram, or FFBD. The FFBD describes the order and sequence of the system functions, their relationships, and the input/output structures necessary to achieve the system requirements

what is timeline analysis model

The timeline analysis model follows naturally from task analysis; it provides the supplemental time-required information for the task analysis, so that time-related workloads for various tasks can be identified. In timeline analysis, graphical charts are often used to provide a visualization tool to lay out the sequence for all the tasks, and based on the research findings of each model, the time information is plotted on the charts to illustrate the temporal relationships of the tasks performed. Timeline analysis is very similar to the Gantt chart model, which is used to present project activity schedules.

although there is no template for function allocation analysis, there are some general guidelines that can be followed.

The transition from an FFBD-based functional model to a function allocation model always starts with a detailed FFBD analysis at the lowest level and function resource analysis for the lowest-level functions.

it is beneficial if the nature of the system allows us to investigate it; it is direct and straightforward, but, unfortunately, studying the system itself is not possible most of the time.Why is that ?

There are several reasons for this impossibility; firstly, the system may not yet exist. For a system design, especially a new one, most of the time we only have concepts; there is no real system available for us to manipulate. Secondly, sometimes it is not feasible to play with the system itself. Studying the system involves manipulation of and experimentation with the system variables; for example, changing the system layout, eliminating some factors or adding new components. These changes require inevitable interruptions to the current system and can be costly if the new design does not work the way we want it to. Moreover, sometimes it is even dangerous to experiment with the real system itself; for example, it may involve exposure to extreme environments, poisons, radiation, and so on. Under these circumstances, interacting with the real system is out of the question.

what is a good starting area for system modeling

Usually, a good starting point for functional modeling is scenarios and use cases, as these describe all the possible uses of the system, and all the functions are embedded within one or more scenarios if the scenarios are complete.

When all the functions are identified, we need to determine how these functions are accomplished. This is achieved by looking at the resources for each of the functions—that is to say:

What are the inputs and outputs for the function? What are the controls/constraints for activating the func-tion? And what types of mechanism are involved in the function? Example control/constraints include technical, social, political, and environmental factors; examples of mechanisms include human, materials, computer, facility, and utility support and so on. This process is performed for every function to determine the best way of achieving it

An alternative to studying the real system is to use

a model of the system.

what is analogue models

analogue models, as the name implies, describe the relations between the sys-tem components. Unlike physical models, where there has to be a proportional duplication of the physical dimensions, in analogue models, although these are still physical in nature, the geometric dimensions are of little importance, but rather the interrelationships among the components are emphasized. For example, electric circuits are utilized to represent a mechanical system or a biological system. In analogue systems, it is not surprising to see that dots are being used as symbols to represent some system components.

Based on the nature of the variables in the model, systems models can be classified as

deterministic or stochastic models

In developing a mathematical model, a typical procedure involves the fol-lowing steps;

first, the objective of the problem is identified by understand-ing the background to the problem and collecting the necessary information about it; second, based on the objective of the problem, a set of assumptions or hypotheses are developed to simplify the situation and prioritize the relevant factors. Assumptions make it possible for a system to be modeled mathematically and quantitatively. This is a critical step, as the validity of the assumptions will impact the validity of the model directly; a valid set of assumptions not only makes a mathematical model possible, but also cap-tures the most critical and essential aspects of system behavior so that the model can reliably predict it. Third, based on the objectives and assump-tions made, the most appropriate mathematical tools are chosen to develop the models. We are entering a wide field of applied mathematics; many tools are available for us to use to solve different problems, including alge-bra, probability and statistics, geometry, graph and network theory, queu-ing theory, game theory, and mathematical programming, to name a few.

Task analysis is a procedural model to identify the required tasks and their hierarchical structure, and produce the ordered list for all the tasks at different hierarchical levels. Based on this, task analysis is also called

hierar-chical task analysis (HTA).

An intuitive way for deriving the functions, especially for a new system

is to highlight all the verbs in the scenarios, and formalize and orga-nize these verb phrases into a functional format. There is no standard method for functional development, as every system is different and everyone has different preferences for how to approach the system. As a rule of thumb, one should always start with the highest level of functions, the major function modules for the system mission, from the very top level (Level 0); the lower-level functions are specified for each of the major function modules. Through this decomposition process, perhaps with much iteration within each level, the complete functional model can be developed

For most of the allocation, it is nearly impossible to achieve an optimal solution why is that ?

ith such a large degree of uncertainty and high level of complex-ity, it is not easy to formulate the problem into a well-structured optimiza-tion problem and provide a solution for it. Most of the time, we are seeking the most feasible solution within our understanding of the system func-tions, knowing the feasibility of current and emerging technology, and with help from the suppliers' catalogue and global supply chain management resources. It is an iterative process that involves intensive decision mak-ing, trade-offs, prototyping, design, synthesis, and evaluation activities. It is believed that with this evolving design cycle, a feasible allocation baseline can be gradually achieved.

When you deal with models, you should note that simplicity is always preferred over complexity. In other words:

keep it as simple as possible. You should also make every effort to create a model that mimics the real world system as closely as possible. How closely a model mimics the real world system is referred to as the validity of the model. For our (talking about the class) purposes, we will be working with system design models. These models and methods address applied research questions. Systems engineers focus on prediction more than a description and use models that are not unique but follow a design sequence. Note that systems models are used iteratively throughout the design process.

From the format of the model representation, models can be classified as

physical, analogue, schematic, or mathematical models.

In system engineering design, task analysis is commonly used, primarily for( may need to expand)

specifying human-system interaction requirements and system interface specifications. It is used to analyze the rationale and purpose of what users are doing with the intended system, and to try to work out, based on the functional objective in mind, what users are trying to achieve and how they achieve the functionality by doing which tasks.

To overcome the personal bias and distortion caused by subjectivity,

task analysis usually takes a team approach by having a group of people involved to achieve a consistent outcome from the team. More research findings, data quality, and iterative checking/balance also help. These will facilitate the task analysis results to be more compatible with users' true behaviors. For these reasons, task analysis models are most commonly used for design purposes, and are not suitable for evaluation, as there is no standard for right or wrong results from the task analysis.

The product for the allocation analysis is the

the identification of the various system elements in terms of hardware components, software components, and human components, together with the data/information and TPMs associated with each element, or type B specification (the allocation base-line). The eventual goal of the function allocation is to know who/which is doing what function, how they are accomplished and by how much (the TPMs), providing a basic configuration for the system elements, so that system con-struction may be carried out in the next step.

Task analysis models are based on functional model structures;therefore

the tasks derived are associated with certain system functions, while functions are the ratio-nale for task activities. function analysis before task analysis

Once the lowest level of system components and elements are identified and TPMs are allocated to those elements, the next step is

to realize these components by configuring the assemblies for the system. When trying to work out the system components configurations, there are some limitations to be considered; one of them is that of the physical dimensions. There are certain requirements regulating the size and number of components to fit in a limited space. Layout and packaging design are issues that need to be considered in configuring the system structure, as mentioned in Chapter 2. Further development is needed to specify the assembly selection (Type C specification: product baseline), manufacturing process/procedures for these assemblies (Type D specification: process baseline), and materials specifica-tions for the assemblies (Type E specification: material baseline). In develop-ing these baselines, traceability has to be ensured to make sure the baselines conform with the systems requirements and design constraints.

role of subjectivity in modeling

, although it is very straightforward and sometimes even intuitive, this also implies that there are no hard and fast rules to follow about how to conduct FFBD analy-sis; designers' experiences and subjective judgment play a significant role in this process. There is a high degree of subjectivity in functional modeling, and there is no easy solution for this. Group decision making, more research findings about the system to be designed, and multiple rounds of iteration through verification and feedback are, perhaps, the only way to overcome this subjectivity

When selecting a component, we should follow the following order or sequence (Blanchard and Fabrycky 2006):

1. .Select a standard component that is commercially available. COTS items usually have multiple suppliers, and those suppliers are usually specialized and mature in terms of their manufacturing capabilities at an economically efficient stage of production. They are also certified and comply with quality standards, such as ISO standards, so we can take advantage of vast volume and high-quality items with the least cost involved. These suppliers often come with a high level of service for maintenance and repair of the components, which is another advan-tage when seeking more efficient and cost-effective system support. 2.If such a COTS item is not available, the next logical step is to try to modify an existing COTS item to meet our own expectations. Simple modifications such as rewiring, installing new cables, adding new software modules, and so on, enable a function to be accomplished with minimum effort, without investing a huge amount of money to develop a manufacturing facility within the organization. 3.If modifying an existing COTS item is not possible, then the last option is to develop and manufacture a unique component. This is the most expensive alternative and should be avoided if possible. As the last resort, we should not attempt to do everything all by ourselves; with the existence of a globalized supply chain, outsourc-ing and contracting should be considered for such a development, to take advantage of differences in costs of resources worldwide, including materials and labor costs. As for the selection of the components, there are no standards for us to fol-low, as each system is different and involves different types of items but, gen-erally speaking, there are some rule-of-thumb guidelines for the designer to follow; these guidelines have been practically proven to be efficient for saving costs and time.

a general approach for link analysis involves the following steps:

1..Identify the objective of the link analysis. What is the purpose of conducting such an analysis? What is the measure of effectiveness and efficiency for this particular problem; that is, are we trying to find the best layout to minimize the total traveling distance among elements? Or, are we trying to put the system elements together in such a way that the total importance index between elements is maximized? 2.List all the elements for the link analysis, including the personnel and items. Based on the relationships between all the elements and the objectives, quantify the links between the elements, including the distances, frequencies, cost, and so forth. 3.Measure the priority/importance score for each of the links if necessary. 4. Develop the from-to matrix for the vertices (for the elements) and the arcs, based on the values assigned. 5.Apply the appropriate algorithms to place the elements in the layout until all the elements have been assigned. 6.Evaluate the final layout by calculating the score for the measures of effectiveness. Implement the layout based on the results.4

A system function has the following characteristics:

1.A function is an activity or an action that the system performs, driven by the system requirements and regulated by technology and feasibility; a function is a desired system behavior. Including a verb is usually a typical way to identify a function; for example, "deposit check" or "withdraw cash from checking account" are two functions for an ATM system, while "user friendly" is definitely not a function, since there is no active verb in the phrase. It may define a property of a function, but not a function itself. 2. A function can be performed at different levels; in other words, functions are hierarchical within the system architecture. A func-tion may be accomplished by one or more system elements, includ-ing hardware, software, facilities, personnel, procedural data, or any combinations of these above elements. A higher-level function is accomplished by a series of lower-level functions; that is to say, higher-level functions are decomposed by lower-level functions. 3.Functions are unique; there are no redundant functions unless redundancy is one of the functions to be achieved. For example, in enhancing system reliabilities, redundant functions are often pro-vided, to be activated when the original function fails. Other than for this reason, functions should be unique, as space and resources are limited in system design. 4.Functions interact with each other. From the same level of func-tional structure, each function takes inputs from the outputs of other functions, while providing outputs to yet other functions. All the functions work together cohesively to support the overall system's highest-level function: the system mission.

There are five common steps involved in a typical CTA analysis:

1.Collect preliminary knowledge: Designers identify the preliminary knowledge that is related to the system, to become familiar with the knowledge domain. Usually, the research findings from the litera-ture and consultation with SMEs are utilized for the elicitation of such knowledge. 2.Identify knowledge representation: Using the preliminary knowledge collected, designers examine it and allocate the task hierarchical structure, based on the traditional HTA structure. Designers may use a variety of techniques such as concept maps, flow charts, and semantic nets to represent the knowledge for each of the tasks. 3.Apply focused knowledge elicitation methods: Based on the different representations of knowledge, designers may now choose the appro-priate techniques for knowledge elicitation. Multiple techniques are expected for a better articulation of the knowledge. Techniques include interviews, focus groups, and naturalistic decision-making modeling; these are the most commonly used methods, and most of the techniques are informal. 4.Analyze and verify the data: On completion of the knowledge elicita-tion, the results are verified using a variety of evaluation techniques, including heuristic evaluations and walkthroughs by experts, or for-mal testing involving real users to demonstrate the validity of the knowledge requirements for each of the tasks. 5.Format results for the system design documentation: The results of the CTA are translated into design specifications so that they will be implemented in the design. Cognitive requirements, skill levels, and users' mental models of task-performing strategies are derived to be translated to design specifications, especially the human-system interface aspects, so that systems functions are accomplished in an efficient way.

An FFBD shall possess the following characteristics:

1.Functional block: In the FFBD, functions are presented in a single rectangular box, usually enclosed by a solid line, which implies a finalized function; if a function is tentative or questionable at the time the FFBD is constructed, a dotted-line enclosed box should be used. One block only is used to represent one single function, with the function title (verb+noun) placed in the center of the box. When one function is decomposed to a new sequence of lower-level functions, the new sequence should start with the origin of the new sublevel FFBD by using a reference block. A reference-func-tional block will indicate the number and name of that function. Theoretically, each FFBD should have a starting reference block. 2. Function numbering: An FFBD should have a consistent numbering scheme to represent its hierarchical structure. The highest level of systems functions should be Level 0 (zero); functions in the highest level of the FFBD should be numbered as 1.0, 2.0, 3.0, and so on. Another benefit of using such a numbering system is to help designers gradually derive the system function structure step by step, in a very organized way, and avoid putting different levels of functions into the same level of the FFBD. Putting different levels of functions into one diagram is called recursive; it is a com-mon mistake often found in FFBD development. Using the number-ing system, it is easy to identify this error. Many software packages can detect the recursive error once the numbering system is in place 3..Functional connection: In an FFBD, functions are connected by lines between them. A line connecting between two functions implies that there is a functional flow between these two functions; that is, one function takes the output of another function as its input, either material, power, or information. If there is only a time-lapse between two functions and no other relationships, there should be no lines connecting the functions. 4.Functional flow directions: Usually, for any function, a typical flow (go path) always goes in to its left-hand side (input flow) and goes out from its right-hand side (output flow). The reverse flow (from right to left) is used for feedback and checking flows. The top and bottom sides of the function are reserved for no-go flow; that is, the flow when the function fails. The flow exits from the bottom of the function and enters the diagnosis and maintenance functions (no-go paths). In the FFBD, no-go paths are labeled to separate them from go paths. Usually the flows are directional and straightforward; the directions form the structural relationships for the functions, such as series structures, parallel structures, loops (iteration loops, while-do loops, or do-until loops), and AND/OR summing gates. These constructs, together with their functions, define the functional behavior model for the system. 5.Numbering changes: An FFBD is an iterative process; it is inevitable that deletion and addition of functions will occur during this process. With the deletion of existing functions, it is simple just to remove the function from the FFBD; for the addition of a new function, a new number needs to be assigned to the new item on the chart. The rule of thumb is to minimize the impact to the rest of the FFBD; although the new function might be placed in the middle of the FFBD, we do not need to renumber the functions to show its position, but we just choose the first unused number at the same level of the FFBD for the new function. In that way, the rest of the functions are not impacted (Blanchard and Fabrycky, 2006). 6.Stopping criteria: The development of FFBD follows a top-down approach, as previously mentioned; it starts at the highest level of the functions and then, from there, decomposes each of the highest-level functions to its next sublevel, and so forth. It is imperative to have a stopping criterion for this decomposition process, because without it, decomposition can literally go on forever. While there is no well-established standard for such a criterion, it usually depends on the nature of the system and level of effort of the design. According to INCOSE (2012), a commonly used rule is to continue the decompo-sition process until all the functional requirements are addressed and realizable in hardware, software, manual operations, or com-binations of these. In some other cases, decomposition efforts will continue until the FFBD goes beyond what is necessary or until the budget for the activity has been exhausted or overspent. In terms of the design tasks, however, pushing the decomposition to greater levels of detail can always help to reduce the risks, as this will lay out more requirements for the suppliers at the lower levels, making the selection of the components a little easier. We will revisit this process later in the functional allocation model.

The typical system elements can be categorized into three basic forms:

1.Hardware/physical elements: These are the tangible/physical com-ponents for building the system, whether static or dynamic, such as the facility, the system frame, parts, wires, and so forth. The alloca-tion outputs are the quantitative and qualitative physical configura-tions of the hardware component. 2.Software elements: These include the computer code and programs that are executed to control the system's physical components. Software elements are responsible for the information flow and data management of system operations. The allocation output is the soft-ware configuration for the component, including the input/output specification and performance specifications, also including certain software platforms and interface structures. 3.Human elements: These include the system operators/users and maintainers. These are the people that directly interact with the sys-tem and fix it if something goes wrong. The allocation outputs of the system functions to the human elements are the human staffing model (number of people and their scheduling), the operation and maintenance procedure, human system interaction specification and the skills and training requirements for the human elements

The major output of an HTA is an ordered list of the tasks that users will per-form to achieve the system functions. Additional information is also gath-ered for the tasks, including

1.Information requirements for each task 2.Time information for each task, including the time available and time required 3.User actions, activities, and operations 4.Environmental conditions required to carry out the task

No matter what kind of model is being developed, there are some common features or things that need our attention across all different models:

1.Models need to have a satisfactory level of validity. Validity refers to the level of closeness of the model to the real-world objects. The closer the model, the higher validity it has. Model validity reflects the accuracy and precision of the models; it depends on different factors, including the prior assumptions of the model and the vari-able selection/logic involved in the model. A valid model is believed to contain the most important and critical variables for the problem; thus, it is safe to use the model to replace the real-world objects for analysis and prediction of system behavior. 2.Simplicity is preferred over complexity. When constructing mod-els, given that the validity requirements are satisfied, simple models are desired for system analysis. Simple and clear models are easier to understand and quicker to build. If a simple model is sufficient to address the problem, there is no need to seek more complex models. In developing models, we should always start with simple methods, avoiding the use of intriguing mathematical concepts; remember that this is an applied field, so generalization is of little use. We should avoid developing models with no possibility of solving them. As a gen-eral rule, more variables are always believed to be more accurate than fewer variables, but we have to be careful about variable selection, and it is not always the case that the more the better; a balance between the complexity and numbers of variables should be sought to maintain a certain level of precision yet ensure a simple and clear model format.

Within CORE, the basic constructs for FFBD include

1.Sequential construct: This is the most commonly used construct; it connects two or more functions together based on their input/out-put relationships. See Figure 4.4. 2.Iteration: in CORE, iteration is used for a repeated sequence; it is similar to a while-do loop, as the iteration condition is tested at the beginning. For example, in the ATM system, if the user inputs the wrong passcode, he/she has two more attempts to enter the cor-rect code; after three unsuccessful attempts, the system will lock the card and disable any further function. The condition (fewer than three unsuccessful attempts) is defined using DomainSet. See Figure 4.5. 3.Select (OR) construct: A select OR construct defines an exclusive OR path; only one path is enabled at a time. See Figure 4.6. 4.Parallel (AND) construct: An AND construct defines a parallel path, where all the branches must be enabled at the same time. See Figure 4.7. 5.Loop construct: This is similar to a do-until structure in computer program languages; it will repeat until a predefined condition is met. Unlike the iteration construct, the loop construct tests the con-dition after each iteration. Every loop is associated with a loop exit construct to allow exit from the loop. See Figure 4.8 6.Replicate construct: The replicate construct is the structure short-hand notation for identical processes that operate in parallel. The coordinates between these functions are defined in DomainSet in the coordinate branch. The replicate construct can be replaced by the parallel construct plus the coordinate branches. See Figure 4.9. A typical example of the replicate situation is a manager overseeing multiple checkout lanes in a grocery store.

what are the common characteristics about system design models

1.System design models and methods address applied research ques-tions. Basic research addresses fundamental research questions; these questions are basic in nature and often lead to general ground theories. These theories may be generalized to a wide range of fields. For example, the study of human skill performance is basic research; the theory behind such performance can be used to explain many kinds of human skill acquisition, such as learning musical instruments or learning how to fly an aircraft. Applied research, on the other hand, addresses specific research questions; for example, how does the location and size of the control button affect the user performance for a specific product interface? Applied research does not care as much about the generalization of the findings from the model; its focus is only on the specific product it is studying. The scopes of the applied research results are narrow and usually can-not be applied to other types of product for this reason. Systems engineering models only serve one specific system; their validity remains within the scope of the system. Although the finding may also make sense for other systems, there is no external validation guarantee for other types of systems unless the results are vali-dated in those systems. Since basic research is conducted in ideal, well-controlled laboratory conditions, its findings have general meaning and wide applicability. Systems engineering models are usually conducted in actual design fields, with high internal but low external validity. 2.Systems engineering models focus on prediction more than description. Scientific research is concerned more about describ-ing the relationships between factors in nature. This is even more so for basic scientific research, as its purpose is to discover truths from evaluating nature around us; in other words, its purpose is the description of natural phenomena to try to give a scientific expla-nation for them. Systems engineering models, on the other hand, focus more on the prediction of behavior of systems and their components. For system design, most of the time when models are applied, the system is just a concept; the physical system does not yet exist. The purpose of modeling is to predict the future per-formance of the system, given certain inputs from the design and current system conceptual configurations. According to Chapanis (1996), application of models in systems development is much more difficult than that in basic research; since, in basic research, as the purpose of modeling is to discover and describe, even if a mistake is made, others can always carry out follow-up procedures based on the previous findings, with better data and analysis, to overcome the deficiencies in the previous studies; thus, the mistakes will be eventually corrected, because science is "self correcting." In systems development, however, it is often not possible that many chances are given to create a design. Once a severe mistake is made, fixing it will significantly impact the system design efficiencies, causing delays and unexpected costs, sometimes even causing unrecoverable system failure. The accuracy of prediction is of utmost importance in systems development. When predicting system performance, applied systems models also rely on the findings from scientific the-ories; in other words, we cannot totally separate the prediction from the description. As mentioned in Chapter 2, engineering originates from science; designing a man-made system requires resources from Mother Nature—a good engineering model is always based on the solid foundation of scientific discoveries. Knowledge of both is a must for a good system designer. We should keep this mind; proper integration between basic scientific models and engineering design models is the key to the success of system design. 3.System engineering models are not unique. Systems engineering is a relatively new field; all the models used in system design are bor-rowed and modified from other fields. This is due to the multidisci-plinary nature of systems engineering. None of the models applied in systems engineering are unique; they were developed in other scientific or engineering fields, and have been adapted for systems engineering design purposes. For example, task analysis has long been used in psychology and social sciences to understand human behaviors; now it is used widely in systems engineering, especially to understand the interaction requirements between users and sys-tems. In using the models, system designers should keep an open mind and be flexible. Since practical and specific answers are the concern, we should make effective use of all models appropriately in the design process. 4.Systems models are used iteratively throughout the design process; during the process, it is not uncommon that one particular model is applied multiple times in different stages. For example, functional modeling is first applied after the requirements are completed to design the system-level functional structure. This is the typical usage of functional modeling at the conceptual design stage. In subsequent stages, functional models are also used to design the subsystem-level functional structures, with similar procedures but different starting points and levels of detail. This analysis is con-ducted iteratively until the final system functional structure is com-pleted. Sometimes, results from the previous models are revisited or reexamined for verification purposes. For this reason, it is difficult to say that a particular model is only used in certain stages; it is very possible that a model will be used at every design stage, depending on the type of system being designed. By the same token, it is also possible that some models are not used at all for one system but used extensively in another system design. Similarly, designers need to keep an open mind when selecting appropriate models for the right system at the right time, by tailoring specific models to the system design needs. 5.Systems models in design follow a sequence. Applications of cer-tain models in systems design depend on the completion of other models, as some models take the results from others as input. This implies that certain models need to follow a particular series sequence. For example, functional modeling has to wait until requirement analysis is complete and task analysis is usually conducted after functional modeling is complete, as tasks are designed to serve certain functions. Understanding the prerequi-site requirements for each model helps us to correctly construct the model at the right time with the correct input, thus increasing the efficiency of the system design.

The following is a list of the fundamental characteristics specifically of systems models:

1.Systems models represent the system and its behavior in a valid, abstract, and effective way. 2.Systems models use the minimum number of factors (variables) to describe the nature and characteristics of the system; these factors are considered most critical for the nature of the system and other factors can be ignored without affecting the validity of the model. In this way, we can simplify the problem so that it is solvable. 3.Systems models describe the relationships between the factors, and system behaviors, effectively and accurately

In CORE, functional modeling is also called functional architectural mod-eling. Its purpose is to define system behavior in terms of functions and their structure, and to define the context in which functions are performed and control mechanisms activate and deactivate the system. Some of the basic functional model-related elements include

1.Use case: In CORE, use cases are "precursors to the development of system scenarios"; they are extremely useful for gaining insights into the system's intended uses, and thus help to lead us to the integrated system behavior models. As mentioned earlier, use cases and sce-narios in the requirement analysis stages tell the stories of how the system will be used once built; they are one of the primary sources for extracting the functions. In CORE, a use case is defined by use caseelements; as in UML, each use case involves one or more actors, defined by components in CORE; each use case is elaborated either by a function element, a programActivity element, or a testActivity ele-ment, depending on where the use case affects the system behavior (system design, program management, or verification/validation). A use case can be extended to other use cases. For example, for the ATM example, a use case could be "withdraw funds from the checking account"; the component would be "users" and would be elaborated by the "withdraw" function. 2.Functions: In CORE, functions are actions that the system performs, just like the functions we defined in systems engineering; they are transformations that accept one or more inputs and transform them into outputs, providing inputs to other functions. A function is based on some requirements, it elaborates some use cases, and it is performed by one or more system components (hardware, software, or human). 3.Item: In CORE, items are the resources or constraints necessary for functions to be performed, representing the flows for the functions. These resources include the materials, power, information, and user input. Items can be input to a function, output from a function or simply trigger a function to start. For example, a typical item for the ATM system's "verify account" function is the passcode for the account; without the user input of this information, "verify account" cannot succeed. 4.DomainSet: In CORE, DomainSet defines the conditions for the FFBD flow logic, such as defining the number of iterations or replications in a control structure, including the while-do, do-until, and IF-THEN conditions for the function decision logics .5.State/Mode: A state/mode in CORE represents certain states or phases in system operations. Recent development of MBSE requires integration with standard design methodology, such as SysML, which has been developed based on UML. System requirements specify different states/modes into which the system may evolve, which can be exhibited by systems components. States/modes are optional for system functional modeling if such items as phase structures are not necessary for the design.

what is deterministic models

A deterministic model describes the relationships between determinis-tic variables; in other words, there is no randomness involved in the state of the models. Not only are the variables not random, the relationships are also fixed. With the same conditions, a deterministic model is always expected to produce the same results. Deterministic models can be com-plex in nature, and although there are definite answers that explain model behavior, such behavior is sometimes hard to obtain. For example, in con-trol systems, some deterministic models are represented as differential equations, and it is difficult to express the state of the system explicitly at a particular point in time. Numeric analysis is one of the most popu-lar approaches to approximate the answers in such a system. We can find many examples of deterministic models in our daily life; for example, most of the models in statics belong to this category, such as Newton's three laws of motion. One particular type of deterministic model that needs our special attention is the chaotic model. This model is considered determin-ist because, theoretically, if the initial conditions are completely known for a dynamic system, its future state can be predicted exactly according to deterministic relations governed by a set of differential equations. But, in reality, it is impossible that the initial conditions of a system are known to the degree of precision required; thus, it is impossible to predict the future trajectory (behavior) of a chaotic system. That is why a chaotic system dis-plays traces of random-like behavior.

In conducting task analysis, it is often found that the concepts of "tasks" and "functions" are confused; some functional models are conducted using a task analysis, and vice versa. what is the difference between task and function

A function, as we have stated many times previously, is an action for which a system is specifically fitted, used, or designed to accomplish a specific purpose. In other words, it is a system action; it is what the system should do or perform. It is usually a more abstract goal or objective—although it involves a verb—but not an overly detailed activity. A task, on the other hand, provides such detail. According to the Merriam-Webster dictionary, a task is "a usually assigned piece of work often to be finished within a certain time." In the systems engineering context, a task is an activity, usu-ally performed by a system component, including hardware, software, or humans, in a timely manner to accomplish a particular function. A task is performed for a purpose; that purpose is a system function. So, system functions come first, and tasks come second, to serve the functions and enable them to be accomplished.

what is a functional flow block diagram (FFBD)

A functional flow block diagram (FFBD) is a multilevel graphical model of the systems functional operational structure to illustrate the sequential rela-tionships of functions.

what is a model

A model is a representation of the real-world system; it is a duplication of the real system in a simplified and abstract form. A model may sound intriguing to most people, but, in fact, we use models and modeling techniques in our everyday life. For example, if we want to describe something, or tell a story, we need to use symbols, language, pictures, or numbers to let others develop a mental picture of the things we are describing or understand the story we are trying to tell. All the artifacts you are using, language, symbols, and pictures, are instances of models. Models are being used at every moment of our lives.

what are schematic models

A schematic model uses a chart or diagram to illustrate the dynamics or structure of the system; unlike physical or analogue models, schematic models may not look like the real system physically. By proper coding of the system elements, using the appropriate symbols and constructs, a schematic system is intended to illustrate the dynamics of current and future situa-tions or hierarchical static structures in that system. A typical example of the schematic model is an instructional diagram for a basketball play, for a coach to illustrate the ideas of offense or defense. A hierarchical chart of an organization is another common example of the schematic model.

what is cognitive task analysis (CTA)

Cognitive task analysis is an extension of the traditional HTA, with more focus on human cognition. Traditional HTA concentrates primarily on the physical activities of humans; these activities have to be observable for them to be recorded. However, in complex system interaction, many of the activities, especially mental activities, are not easily observed. For tasks that involve many cogni-tive activities, a slightly different approach than the traditional one is neces-sary to capture the cognitive aspects.

Procedure of HTA

Designers take a team approach by integrating the information together for task analysis. Designers usually start from the highest level of the FFBD for each of the functions; based on the input, output, and resources/constraints information, designers use their experience and knowledge of the system and its functions, listing all the required tasks, describing them, putting them in order, and decomposing them into subtasks if desired. This procedure goes on until all the tasks are identified and no further decomposition is needed.

Benefits of Using models in systems engineering. what are they

First, models allow us to study system concepts without directly interacting with the systems themselves. Some systems do not exist, except in their conceptual stages; some systems have a larger scope, beyond the capability of design teams, such as the social system and environmental systems, while other systems involve dangers that prohibit direct human interaction. Because models are duplicates of systems, they concentrate only on the most critical factors; ignoring the irrelevant factors enables us to focus on the most important aspects of system behavior. By doing this, we can make complex system relationships simpler and easier to be inves-tigated. Second, it is much quicker to build a system model than to build the system itself, not to mention a lot cheaper too. Models range from simple sketches to scaled-down system mock-ups, and are a lot easier to develop, especially with modern technology and advanced computer hardware and software. During the process of system design, along with the evolvement of the system, many of the system parameters are not at the optimum operational level; constant testing, evaluation, and system modification are necessary, and the effect of system mod-ification will not be identified until it is implemented. Interrupting the operating system without confidence in the model can cause lots of problems. Once the model is built and proven valid, that is, it truly represents the correct system behavior relationships, this enables designers to experiment and manipulate it with minimum effort, and various design ideas and modifications can be applied and tested without disrupting the real system, while maintaining a certain level of accuracy of prediction of the effects of the design changes on the system. In other words, even if our experiments fail or we mess things up here and there, we can start over again without costing much to the real system. Building systems models is one of the most important activities involved in systems engineering; it allows engineers to analyze the nature of the problems, leading to their solu-tions, thus achieving the technical goals of the design and bringing the greatest economic benefits.

Models can be classified based on format or based on variables. Format models include: Physical models Analogue models Schematic models Mathematical models Variable models include: Deterministic models Stochastic models

Format models include: Physical models Analogue models Schematic models Mathematical models Variable models include: Deterministic models Stochastic models

Functional modeling and analysis is one of the most important analyses in systems design; its intention is to develop a functional structure for the sys-tem, based on the systems requirements. Explain in detail

Functional modeling and analysis is the very next step after systems requirements analysis, to identify what system functions shall be provided, what structure shall these functions should follow, and how these functions shall interact together in an optimal manner to achieve users' needs efficiently. Functional models provide a picture of what functions that system should perform, not how these functions are implemented. In model-based systems engineering (MBSE) design, we want to evolve the system from one model to another, following a strictly defined methodology and a tightly controlled process, to minimize unnecessary changes and rework. This top-down approach will ensure a natural transition between models; going beyond the model's scope and over-specifying the details before its maturity often cause rework issues. It is a common mistake that, in system functional models, physical models are blended within the function, leading to partial understanding or even an incomplete picture of the functional structure, narrowing the potential problem-solving space for future models.

what is the input for system functional modeling

Functional modeling uses information from system requirements analysis, including scenarios, use cases, analysis of similar systems, and feasibility analysis.As mentioned earlier, taking this input information, designers start to identify the highest level of functions and decompose the higher-level functions into lower-level functions through an iterative method. Functions are formally defined, including the desired technical performance measures (TPMs) for the functions, such as power, velocity, torque, response time, reli-ability, usability, and so on; function structures are developed and traceabil-ity between functions and requirements, and between functions, is recorded.

what is the stochastic models

In contrast to deterministic variables, there are random variables, which take a possible value from a sample space without certainty. Models that address random variables are called stochastic models, sometimes also referred to as stochastic processes. Probability and statistics are the most commonly used mathematical tools for developing and solving stochastic models. Randomness and uncertainty is everywhere in our daily life, as also seen in system design. Risks caused by environmental uncertainty can have a signif-icant impact on system design efficiency and effectiveness. Understanding, analyzing, and controlling the level of randomness in the system design is very critical for system success. This implies that stochastic processes are widely applied throughout the system life cycle. Stochastic models take ran-dom input and produce random output. They use large samples to overcome individual indeterminacy, giving a likelihood of an outcome rather than a definite answer for given input values. In systems engineering, discrete sto-chastic models are very useful for analyzing system behavior and assessing design risks; these models include time series models, as seen in forecasting models, queuing models for a production process, and human factors per-formance data and modeling. We will be discussing each of these models in later chapters.

methods useful for a empirical answer

It is difficult to obtain an analytically definite solution for many complex models; for the purpose of system design, an approximate answer or near-optimum solution is often sufficient. Many techniques, such as graphical approach, numeric analysis, and simulation are very useful for reaching an empirical answer.

what is link analysis

Link analysis is a model derived from network and graph theory; it is concerned with the physical arrangement of the items so that the efficiency of operations between the items is optimized. These items include workstations, instrument panels, machines, offices, or any work areas involved. Network and graph theory is an important area of operations research, and since the 1970s, the application of network and graph theory has bloomed due to the increasing demand for large, complex facilities and layout planning. A graph is represented by a set of vertices and edges (sometimes called nodes and arcs/lines). A network is a graph with numbers associated with each edge or arc; these numbers could be the distance, cost, reliability, importance, frequencies, or any related parameters. The application of graph and network theory in systems engineering is also referred to as the link analysis model, as it studies the linkage between different elements within the system. Link analysis enables designers to visualize the spatial relationships of systems elements and quantify the parameters involved for these relationships; thus, the overall effectiveness of the links can be optimized.

There are many other classifications of systems models, depending on the different perspectives of looking at them. For example, based on the scope of the models, there are macromodels and micromodels. What are macromodels and micromodels

Macromodels address issues in a large population and across a wide range of areas; for example, macroeconomics models to investigate financial situations in a region or a country. Micromodels, on the other hand, are usually focused on a small scope or problems in a single area; for example, models for a factory or for a production line are models at a microlevel, as these are very narrow and focused on a small area.

what is a mathematical model

Mathematical models describe systems using mathematical concepts and language. Based on observed system behavior and data, mathematical models formulate the system into a set of assumptions, variables, formu-las, equations, and algorithms to illustrate the relationships between system variables. For example, designers often use linear programming models to optimize system resources allocation; or, a set of differential equations are used to describe the dynamics of system control. Mathematical models are very powerful tools to study the underlying fundamental laws and theories behind system behavior. They reveal the basic cause-effect relationships of systems variables, so that systems can be measured, controlled, predicted, and optimized. They have been commonly used in systems engineering. Of all the mathematical concepts being used in systems, operations research is one of the most popular mathematical modeling tools. It is an applied mathematical field that aids designers to make better decisions, usually concerning complex problems. As a matter of fact, the majority of the mod-els covered in this book belong to the discipline of operations research. Operations research originated in military efforts before World War II for the optimal deployment of forces and allocations of resources; its model-ing techniques have since been extended to address different problems in a variety of industries.

Chapter 4 summary

Models are the abstract representation of the real system; they play an important role in systems, as they make complex systems simpler, so that the relationships between critical variables may be investigated. In this chapter, we defined the models in the systems engineering context and identified the major characteristics and benefits of using models in systems design. Models used in systems design can be classified into different categories, based on different perspectives. Based on the format, models may be categorized as physical models, analogue models, schematic models, or mathematical models; based on the variable types, they may be categorized as deterministic or stochastic models; based on the model's scope, there are macromodels and micromodels; based on the model's functions, there are forecast models, decision models, queuing models, and so forth. For each of the categories, descriptions of their significance and examples were given for a better understanding. In terms of systems engineering models, it is noted that most systems design models are applied research from nature and focus on the prediction of system behavior; they are borrowed from other disciplines and modified for systems design purposes. These systems engineering design models are used iteratively in the system life cycle, with various levels of detail for different iterations . Systems models and analysis are the main theme for this whole book; in almost every chapter, different types of models are reviewed. In this chapter, some commonly used design models were discussed, while trying not to overlap too much with the remainder of the book. Two major design models, the functional analysis and function allocation models, were reviewed in great detail. System functions were defined, and their characteristics, syntax, and the FFBD graphical method was explained. As a hands-on exercise, we used CORE as a platform to illustrate how to usesoftware to conduct FFBD analysis. An ATM system was used as the example of function analysis. Function allocation and the relationship between different design baselines (Types A, B, C, D, E) were discussed at the end of the FFBD analysis section. Following functional modeling, task analysis and cognitive task analysis (CTA) were introduced to obtain the interaction design specifications between the users and the system. The input and output for these models and general procedures are given for conducting a task analysis. The last section of this chapter was dedicated to link analysis. The two most commonly used link analysis models were reviewed: graph-based layout planning and center of gravity models to determine facility location. The procedures were elaborated with numeric examples and their application to systems were discussed.

what is a physical model

Physical models are the geometric duplicate of the system, usually in a scaled-down format; they concentrate on the physical, dimensional aspects of the system, including the geometric shape, orientation, color, and size; for example, a three-dimensional mock-up for a product prototype, a ground simulator for an aircraft cockpit system, or a layout plan for a plant facility. Physical models are used primarily for demonstration purposes and some-times for experimenting with the system. For example, a building mock-up is utilized as a template for the layout of the departments, personnel, and machinery for a better flow. The most important aspects in a physical model are its physical dimensions and the spatial relationships between the components, such as the size and orientation of these components and the physical interaction between them.

Input Requirements (HTA)

Starting from the functional model, inputs for task analysis include the func-tion list, architecture, and the FFBD, supplemented with the understanding of the function and technological requirements, research findings from the literature, observations from the users, and expertise and experiences from the subject matter experts (SME).

Task Analysis and human in the loop

Task analysis has been a popular tool for applied behavior science and software engineering since the 1980s; it gained popularity due to its abil-ity to include humans in the loop and its straightforwardness and simplic-ity. System designers use this method to investigate the human components allocation, especially their skills and the staff model based on the task requirements.