4.2 - Alternatives and System Modeling

Alternatives and Modeling Approach

In previous Systems Engineering steps we identified functions that make up parts of a project, and assigned what these parts are supposed to do in terms of requirements. The next several steps are intended to find the best design to meet these requirements. In this section we look at developing alternative options and incorporating them into a complete system model. In the next section we will show how to use such models to optimize and select among the alternatives. These steps are described in sequence because books are a linear sequence of words. But in practice, developing a complex design is not a strictly linear process. As the pieces of the design are identified and the designers exercise their creativity, new arrangements and options will suggest themselves. So the design will evolve partly through an iterative process with feedback from later steps. These steps provide an organized way to start the design process, but they are repeated as many times and at as many levels of detail as needed.

Developing Alternative Options

Developing alternatives is further divided into several steps. In order to not miss any valid options we first identify all currently available and possible new technologies and methods to perform a given function. This identification typically needs researching the state of the art or specialists who understand the field. The initial survey does not limit options by state of development or practicality, since research and development within a project may bring them up to needed levels. A feasibility analysis then eliminates some of these technologies. The elimination is based on factors like not meeting one or more project requirements, or cost of R&D vs likelihood of success. The remaining options are then sized or bounded to an appropriate range for meeting project needs. Within that range, their design parameters are then quantified in terms of mathematical models, design drawings, and other design information. It should be kept in mind that the final design may end up using more than one technology or method. For example, an airline obviously uses airplanes, but may have other vehicles for fueling, baggage handling, etc.

Identifying Technologies and Methods

If the design team is sufficiently large, it will contain specialists in different subjects. They can then be assigned to investigate alternatives for the various functions in the project according to their experience areas. If the team is small, or a single person (as it is for the book author at present), then the designer(s) have to gather information from other sources to come up with a list of options. Even projects that later become large tend to start out small, so gathering technical information outside one's area of experience is often necessary. Tasks for doing this include:

Identify Relevant Fields by Function - Use the words in the function title and description as search terms in general search engines such as Google, and general and specialized reference sources. If you are not familiar with the fields identified by these methods, read some introductory articles or material to gain a basic understanding of their scope. You can then gather more detailed information on the field by standard methods of library and online searches, finding experts to ask, social networking, contacting companies in the field, etc.

Develop Lists of Candidates - From the previous search and data gathering, make a list of items that might apply to performing the function. This includes existing ones, and new items that would require research and development. Items that require too much development will be filtered out later, our aim is to be inclusive at this point. It also includes items that only do part of a function and need to be combined with other items to perform it completely. The list of candidates is then documented, according with the data sources and reasoning for how they would apply to the design.

Feasibility Analysis

The list of candidates is then compared to the project requirements to determine if it is feasible to use them, or if they cannot meet one or more of them. Common reasons to not meet requirements include technical performance or scale, readiness for use within the project schedule, or excessive cost, but any requirement can be a cause for elimination. Technologies which are not fully developed should not be rejected solely for that reason. If they can be developed at reasonable cost, within the project schedule, and reasonable performance risk, they can be carried to the next steps. It is likely that some technologies will be marginally feasible, or there is not enough information to decide. In that case, they should be carried forward and more work done to develop the details. As the design progresses, more candidates will be found infeasible and eliminated, or feasible but less highly ranked, until the best options become evident.

As with the other steps, the data, reasoning, and choices regarding feasibility are documented. We emphasize documentation throughout the design process because typically the design team starts out small and grows over time, and because technology in general does not stand still. A small team cannot know everything about every technology, and later members can fill gaps or add better information to the work. Having the past design logic clearly recorded helps in this process. Progress in a technology may make it a better option or feasible where it was not before, and being able to trace the previous design decisions helps in making updates.

Option Sizing

In the next step, the feasible options are sized against the project needs. Since functions interact with each other, we may not know at this point the required size, for example, of the electrical power supply. Therefore we establish a generous range that covers the eventual needs. Thus if we estimate we will need 100 kW of electricity, we might size the different power supply options over a 10 kW to 1 MW range, so that the actual need will very likely fall within that range.

Design Parameters

Design parameters will vary with size. For example, the motors and batteries of a robotic vehicle will grow as the cargo dimensions and mass increase, but the control electronics may stay the same. In a tall building, increasing height requires larger support columns and more elevators. These kinds of relationships are often not linear or start at zero. For example, you can't have half an elevator. Mathematical models, graphs, dimensioned drawings, and other design information, express these relationships between performance and design features.

Building System Models

Once the feasible alternatives have been identified and sized, and we have information on how their parameters vary, we can start to build models of complete system elements, and the project as a whole.

The Need for Models

In a complex project, the interactions and effects of multiple functions on each other and on the outside environment are also complex. For the whole to correctly operate, the various functions and flows must each be sized correctly. For the design to be optimized, the effects of choosing among alternatives for a given part on the entire system must be understood. Manual resizing and recalculation of all the design parameters for each change would be too slow, prone to error, and tedious in the extreme. Therefore we build mathematical models to describe the system, and use computers to help recalculate, simulate, and optimize. Optimizing the overall design before working on the details or building physical hardware saves on effort and cost in the long run.

System Modeling

In essence, a model is a simplified representation of a system and its parts. In abstract form, mathematical formulas, tables, and other analytical and numerical elements link the system to the outside environment, and describe the parts of the system and how they relate to each other. The elements of a model are based on design information developed for the various options, general engineering knowledge, or best estimates when such information is not available. A variety of software tools and methods are available to implement the models and perform the necessary calculations. These range from simple spreadsheets, to numerical analysis software, to simulation software for individual elements up to entire factories.

Multiple software tools may be needed to completely model a complex system. Outputs from one kind of tool are often used as inputs to others, linking them to form a full system model. The choice of which tools to use and how to connect them depends on a number of factors. These include the level of detail the design has reached, how well available tools are suited to the task, past experience, and available staff and funds. Overly detailed modeling may not gain enough design improvement to be worth the effort to create them. Thus the modeling process is itself subject to design and optimization for a given project. As a design evolves, the models will develop in parallel, from simple to more complex and detailed. So the tools used in the early stages are often not the ones used later. When considering how to model a given project, thought should be given how to transition data from one tool to another as the work evolves.

Establishing requirements and defining functions to meet those requirements should not presuppose a design solution, so as to not exclude a better alternative. Therefore the system modeling process should allow for alternatives until the optimization and selection is done. Even then, further work may find a better solution and change the selected alternatives. The model and data contained therein should be considered the latest version developed so far, but always subject to updates and improvement. In planning and developing the models, they should be built in such a way that changes can be easily made. Selecting options may also happen at different times in the design process for different parts of the system. So the models should allow for incremental changes. In some cases the difference between options is large and evident early. In other cases more detailed work is needed to define the options to the point a choice can be made. So the models should be able to carry multiple options until final choices have been made.

Model Elements

Models are built from simpler elements which are linked in various ways. In the early stages of design these simple elements may be the entirety of the system model. As design progresses, simple elements may be replaced by more detailed and accurate sub-models. Model components include:

Tables and Graphs - Tables can list options, such as various battery technologies for a robotic vehicle, and performance and features related to each. In the case of existing components and materials, tables can list available choices. Graphs can display situations where parameters vary continuously rather than being discrete options or choices.

Parametric Equations - These relate one variable quantity based on other quantities in the system. For example, a furnace's required power input can be related to the kg/hour of material to be heated times the specific heat and temperature difference in the process. Varying the production rate during analysis of the whole system will then also change the required power level.

Annotated Diagrams - The same kind of functional diagrams described in section 4.1 can be used for modeling system elements. The function boxes and flow arrows are annotated with quantities or formulas along with their text labels.

Model Types

The model elements listed previously do not react to changed inputs when they are in the form of bare tables, formulas, and diagrams. They must be embedded in software to automatically propagate changed entries to the rest of the model.

Spreadsheets - The common spreadsheet, such as Microsoft Excel, is a useful tool for system modeling. Most designers are already familiar with this kind of software, and formulas, tables, and even active diagrams are relatively easy to build. It has some drawbacks for more complex and detailed modeling. These include lack of automated detection for missing flows and functions, or ability to simulate physical processes. Nonetheless it is well adapted to early system modeling, and as a summary of more detailed models.

A spreadsheet type model can adopt a tabular or diagrammatic layout, or a combination of both. In tabular form, a conventional way to organize it is by grouping function boxes and the flows which enter and leave them as rows. Where multiple alternatives are being modeled, they are listed as additional rows, with a use factor from 0 to 100% applied. By changing the use factor, you change which alternative is being included in the calculations. This includes mixed alternatives, for example using both solar panels and wind turbines as power sources in varying amounts for the total power required. Columns in the table represent different kinds of resources making up a flow. For example, a metal casting operation might require some kilograms of raw metal and kiloWatt-hours of electricity to melt it as input resources. A function which consumes a resource has a negative value for the quantity, and one which outputs a resource has a positive value.

Columns must eventually sum to zero, meaning every input used has a source supplying it. Otherwise you are implicitly creating or destroying a resource from nothing, and the model is therefore incomplete or needs the values adjusted. When they sum to zero, the resources are balanced in the accounting sense. This is the same as in double-entry bookkeeping, where assets and liabilities (positive and negative money values) must be equal and thus sum to zero. Financial resources are in fact one of the resource types that can be included in a system model. Balanced resource accounting generalizes what was first developed for money accounts to tracking all types of resources in a project - labor, materials, machine output, energy, or anything else.

Numerical Analysis and Simulation Software -

Design and Manufacturing Software -

Integrated Models and Suites - The trend in engineering design has been towards integration of design data, models, and simulation into single programs or suites of related software. Partly this has been enabled by much more powerful computers and networks. Integration removes much of the work in moving data between 3D design models, system models, simulations, and other computer-aided design steps. It speeds up the design process by feeding changes more quickly to other parts of the design. Commercial suites are rather expensive, and typically need time to learn how to use the various parts efficiently. They are better suited to larger design teams in the later and more detailed stages of the design process.