The collection of blog articles posted on this site is now available in book form for $19.50. You can order it from Create Space or from Amazon . The book includes edited versions of the blog articles plus other typical features of a book such as a table of contents and index. The title of the book is Modern Methods of Systems Engineering: With an Introduction to Pattern and Model Based Methods.
You can learn more about the book and the authors at our web site. Our plan is to add additional material to this blog as the authors feel it can contribute to systems engineering methods. This material will be added as it is available rather than on a regular weekly basis. The authors welcome comments on any of the blog articles and corrections, suggestions or other comments on the book. If any readers have material they feel contributes to systems engineering methods that isn't covered in the book please contact us via a comment and we will consider adding your material to this blog.
Showing posts with label system design. Show all posts
Showing posts with label system design. Show all posts
Saturday, December 10, 2011
Tuesday, October 11, 2011
12 Integrating Modern Methods for Faster Systems Engineering
12.0 Introduction
In chapter 2 it was explained that the best model for system development is the “craftsman” model that was widely used before systems became so complex that a single chief engineer could no longer understand a system in sufficient detail to control all aspects of design. System engineers, design engineers and other specialty engineers became necessary to handle the complexity of modern systems. Although this new approach has enabled the development of very complex modern systems it takes much longer to develop a system now than it used to take when a chief engineer and his/her team could develop a new system in a few months.
One objective of this book is to introduce new methods that enable the systems engineering work on system development to be accomplished faster and more accurately. This book has an emphasis on systems engineering fundamentals, as described in the DoD SEF and the NASA SE handbook, and readers will note that it takes time and discipline to follow these fundamental processes. Complex systems cannot be developed cost effectively by shortcutting the systems engineering fundamentals; what is necessary is faster and more accurate methods for executing these fundamentals. Accuracy is required because any errors in systems documentation results in costly “find and fix” efforts later in design or in integration and test. Several methodologies for ensuring accuracy have been discussed including using graphical models in place of text as much as possible, employing redundant tools for developing documentation, using modeling and simulation to support requirements analysis as well as design and checking work at the three levels of worker checking his/her work, peer reviews and design reviews.
In chapter 5 pattern based systems engineering was introduced, which when properly implemented, can dramatically reduce the time to produce much of the top level systems engineering documentation and at the same time increase the accuracy of requirements definition. Similarly using validated system performance models and simulations throughout the development cycle aids in reducing development time and increases the accuracy of requirements and design concepts and the robustness of systems.
The objective of this chapter is to describe methods for reducing information latency and then to show how integrating modern methods can achieve greatly reduced time for systems engineering work without sacrificing any process fundamentals critical to the accuracy of this work. Information latency is the time between when information is generated and the time it is available to others who are depending on the information for the next steps in their work. Information latency was increased with the evolution from the craftsman model for product development to models with systems engineers; this is the primary reason modern systems take so long in development. Reducing information latency to levels near what it was for the craftsman model is a necessary step in achieving faster system development cycles.
12.1 Integrated Concurrent Engineering
In the 1990s a method emerged for reducing information latency for system development teams. This method is similar to methods used previously when teams of workers were brought together in a common work area to collaborate to quickly accomplish some project. Many organizations in the aerospace and defense industry use special work areas to collocate the people writing and publishing proposals, which are often highly time constrained projects. The use of proposal preparation rooms with personal dedicated to working in these rooms results in highly productive teams for the limited times involved in typical proposal efforts. A major part of the increased productivity is due to the reduction in information latency achieved by having workers so close they can ask questions of one another and get immediate answers. If teams tried to maintain such intense work over long periods productivity would taper off due to workers being unable to maintain the long hours and intense work without burnout.
The methods that evolved in the 1990s achieve the reduction in information latency and the associated productivity gains of the colocated teams and permit teams to work effectively for long periods without burnout. These methods became possible by exploiting new technology as well as new work management methods.
The availability of inexpensive large screen display projectors, n to one video switches and inter/intra nets makes it cost effective to set up special work rooms where teams of 10 to 25 knowledge workers can gather with their laptops and software tools. These teams can simultaneously work and share the work results with the entire team on the large screen displays as fast as the results are available. Many organizations now use such facilities for teams to gather for intense work and information sharing periods of three to four hours two or three times weekly. These sessions must be well planned and workers must come prepared to work and share results in real time. Planning, documenting work and time consuming tasks are performed in between the sessions in the special work rooms. This approach is called by a number of names but Integrated Concurrent Engineering (ICE) is a common name. This approach is effective because it reduces information latency from minutes to seconds or hours to minutes.
ICE is proven to reduce cost and schedule of complex projects by factors of three to ten 12-1, 12-2. Neff & Presley 12-3 reported that the Jet Propulsion Laboratory initially achieved an average of over 80% reduction in project costs and significantly improved the quality and speed of work. With more experience a 92% reduction in design time and a 66% reduction in cost was reported. Designs produced using ICE are of higher quality because they examine each option in greater detail earlier in the design process by sharing thousands of design variables in real time. Approaches that are proven to reduce cost and schedule by factors of three to ten and increase quality at the same time should not be dismissed by organizations that wish to remain competitive.
The benefits of ICE are better understood by examining the work space and the work process in more detail. There is no single best work space design or work process; each organization tailors both to their views and their business processes. Examples presented here are guidelines for understanding ICE and not necessarily the best for any specific organization.
12.1.1 The ICE Design Command Center- A schematic diagram of a small ICE work area is shown in Figure 12-1. The room has large screen displays located where they are visible to everyone in the room. Several displays are used so that several different types of information can be displayed simultaneously. Each skill cluster has workers with common specialties and each worker has computer equipment and the design, modeling and simulation tools associated with his/her specialty. Alternatively each cluster can be an IPT responsible for a segment of the system design. Each of the computers is connected to one of the large screen displays via a video switch so that the results of analysis, modeling or simulation can be shared with everyone in the room on one of the large screen displays. The facilitator, typically the lead systems engineer for the systems engineering phase of development, is responsible for maintaining the design baseline visible to all at all times and to lead the team through a preplanned sequence of analysis tasks that lead to design decisions in real time.
12.1.2 The ICE Concept of Operations - Integrated Concurrent Engineering is a repeating series of planning sessions followed by team work sessions, followed by documentation and follow-up analysis in parallel with the planning for the next series of team work sessions. The times for each of the components of the ICE cycle are dependent on the type and complexity of the system being developed. Example times are given here to explain the concept of operations. Development teams are likely to find adopting this concept of operations to their systems development requires adjustments. A typical approach is illustrated in Figure 12-2 where a series of three plan/ meet/document sessions are shown and each of the meet or design sessions is comprised of three intense team sessions separated by a day or two. Individual design sessions may last from two to four hours.
The planning, indicated by A in Figure 12-2, is done by team leaders and might take a week to plan a series of three intense work sessions, indicated by B, over another week period. The series of work sessions is followed by perhaps two weeks of documenting work done in the design sessions and carrying out analyses that takes too much time to be done in design sessions. In the example shown in figure 12-2 nine intense design sessions are planned, executed and documented in a an eight week period. Note that since the design sessions are the only activities that require the ICE design command center such a center can support three or four ICE projects or separate IPTs of a large project concurrently.
12-1 The Integrated Concurrent Enterprise by David B. Stagney, MIT Department of Aeronautics and Astronautics, Sloan School of Management, August 13, 2003
12-2 Observation, Theory, and Simulation of Integrated Concurrent Engineering by John Chachere, John Kunz, and Raymond Levitt, Center For Integrated Facility Engineering, Working Paper #WP087, Stanford University, August 2004
12-3 Implementing a Collaborative Conceptual Design System
– The Human Element is the Most Powerful Part of the System by Jon Neff and Stephen P Presley, IEEE, 2000.
Monday, June 6, 2011
Managing to a Baseline System Design
We now turn to the next step for systems engineers after the first system design concept is defined. This next step is the subject of chapter 8.
8 Selecting the Preferred Design
8.0 Review and Introduction
Selecting the preferred design involves several types of systems analysis tasks including: trade studies, risk assessment, cost modeling, performance analysis/modeling and simulation. Before describing some of these processes it is helpful to review several points from chapters 5 and 6. Trade studies, assessment and analysis are involved in each of the three major steps in the systems engineering process. Referring back to the systems engineering process described in Figure 6-4 shows that iteration takes place not just between each of the major steps of requirements analysis, functional analysis and design synthesis but also between each of these steps and the systems analysis processes of trade studies, modeling and simulation included under technical management. Figure 5-1 illustrates how these systems analysis tasks support the decisions involved in flowing down requirements. Chapter 6 discussed how functional analysis is involved in the flow down of requirements and how systems analysis supports allocating requirements to functions. Chapter 6 also discussed the value in considering many design alternatives at each stage of design synthesis but particularly during concept design. The preferred process for considering design alternatives is to arrive at a baseline design and then conduct trade studies of alternative designs. It is systems analysis processes that aid in selecting the preferred design from the alternatives studied. This chapter describes methods for conducting trade studies, provides an overview of modeling and simulation and introduces some additional diagrams that are useful in describing design concepts.[J1]
8.1 Baseline Concept Management
Project leaders must strive for a balance between forcing decisions too early so that promising alternatives are not considered and leaving too many decisions until just before major design reviews so that the design details are unclear. The standard process for achieving this balance is forcing a design baseline as soon as possible and then conducting trade studies of alternatives to the baseline. This facilitates having a controlled process for making decisions to adopt changes to the baseline and it enables all team members to have the same view of the baseline design at any time.
As soon as the top level function and physical diagrams, the system level specification document and the ICD are complete declare this documentation to be the baseline design. It’s ok that many assemblies or even subsystems are immature; just use the team’s best guesses, but do include as much detail as is available. The baseline design documentation should be maintained where it is available to all team members but no changes to the documentation are allowed without a formal decision process being executed.
As the design progresses and trade studies are performed use the baseline as the starting point and the reference for trades and design decisions. If analysis or trade studies suggest the baseline should change and the project leadership, including the lead systems engineer, agrees then the change is made and the lead systems engineer should notify all key engineering participants that a design change to the baseline has been made. Then the baseline documentation should be updated.
Following this simple baseline management process ensures the whole team is working from the same design data base at any time and it facilitates a controlled design decision process.
Tuesday, April 12, 2011
Guidelines for achieving the best design concept
6.6.2 Decision Management during Design
The degrees of freedom of a design are greatest and the cost to make a design change is lowest during concept design. This is illustrated schematically in Figure 6- 32. The high degrees of design freedom means that design alternatives are relatively unconstrained as long as they map to the functional architecture and meet the functional requirements. In general, the greater the design degrees of freedom the greater the potential for influencing performance, life cycle cost and other important measures of design quality. Decisions made on top level architecture during concept design not only directly reduce the degrees of freedom but these decisions often constrain the design alternatives available at lower levels of the system hierarchy addressed in preliminary and detailed design. This argues strongly for conducting the most extensive exploration of design alternatives during concept design.
Figure 6-32 Design alternatives cost less to explore and have a greater potential influence during concept design.
The objective is to sufficiently explore alternative concepts that high confidence is achieved that the selected design concept is “best” from a number of measures. These measures include the obvious of high performance on high priority customer requirements, low life cycle cost, excellent “ility” measures (manufacturability, testability, reparability, etc.), and perhaps attractive features that might increase sales. Thus there is a tension between the need to make design decisions quickly and to explore a wide range of design alternatives. Once the desired concept design is established, i.e. a baseline design is defined and trade studies are conducted to select the best alternative for the final baseline, then the design freedom is reduced so the opportunities to significantly improve the design are also reduced.
A standard approach to achieving the desired characteristics in concept designs is to seek modular designs. Here the term module refers to design elements, i.e. subsystems, assemblies etc. Modular designs are achieved by refining the allocation of functions to physical modules and partitioning functions between the modules.
6.6.3 Partition for Modular Designs
The DoD SEF says modular designs have the three desirable attributes of low coupling, high cohesion, and low connectivity. Coupling is the amount of information shared between modules; the lower the amount of information that must flow between modules the more independent they are. Having low dependence lowers design risk and makes future upgrades or modifications easier. Cohesion is the similarity of tasks performed within a module. High cohesion leads to easier and less complex designs. A design for which a single component performs multiple functions has high cohesion. Connectivity is a measure of the internal interfaces between modules. A design that has multiple interconnections between the internal parts of one module and those of a neighboring module has undesirable high connectivity, which again complicates design, integration and testing as well as future upgrades.
Note that modularity is a measure of system complexity; the higher the modularity the lower the complexity. Risk is a measure of the complexity of the development program; the higher the risk or the more risks that a program has the more complex the development becomes due to the work necessary to mitigate risk. Modularity and risk are related. A system concept design with low modularity is usually higher risk than a design with high modularity. Therefore to achieve the lowest program risk design concepts should be traded to find the highest modularity. However, risk must be evaluated for each concept to ensure that in striving for higher modularity unnecessary risks haven’t been introduced.
Subscribe to:
Posts (Atom)