System Integration

Jeffrey O. Grady

• Publisher: CRC Press
• Year: 2020
• eBook ISBN: 9781000142198
• Topic: Computer Science
• Subtopic: Computer Engineering
• Index: Computer Science

System Integration presents the systems approach to complex problem solving and provides a powerful base for both product and process integration. This unique reference describes 27 kinds of integration work, primarily obtained through human communications. Simple computer applications-already in place in most companies-have the resources to encourage the availability and sharing of current team knowledge, which results in an intense, cooperative experience leading rapidly to sound design solutions.

Part I

The fundamentals

1 Introduction

2 The human basis for integration

3 Organizational structure

4 Integration components, spaces, and cells

5 Information systems and communications

chapter one

Introduction

1.1 Integration. What is it?

One of the most often used words, yet most neglected notions, in the application of the system engineering process in industry is the word integration. It is a word like system. It has so many meanings and shades of gray that the listener or reader is never quite sure exactly how another person is using the word. Whatever integration is, however, it is a universally accepted necessity in the development of complex systems. It is at the downstream end of an organized process of decomposing complex problems into many smaller related problems, solution of the smaller problems by teams of specialists, and integration of the results into a solution to the original larger problem.

The system integration process is the art and science of facilitating the marketplace of ideas that connects the many separate solutions into a system solution. System integration is a component of the system engineering process that unifies the product components and the process components into a whole. It ensures that the hardware, software, and human system components will interact to achieve the system purpose or satisfy the customer’s need. It is the machinery for what some call concurrent development.

The general approach in system engineering involves decomposing a customer need into actions or functions that the system must satisfy in order to satisfy that need. These lower tier functional requirements are then allocated or assigned to specific things or components in the system. These allocated functions are translated into performance requirements and combined with design constraints to form a set of minimum attributes (requirements) that a design team must satisfy in order for the component to fit into the overall system solution.

These requirements are synthesized by a team of engineers into one or more design concepts and, if more than one, the alternatives are traded one against the other to select a preferred solution. The design concept is expanded into a preliminary and detailed design interspersed with reviews to assure the team is on a sound path to success and in agreement with the work of other teams. Specialists from many disciplines work with the principal designer or design team to assure that the solution accounts for specialty requirements with which the designer may not be fully familiar.

Designs are translated into manufacturing planning and procurement decisions and production and procurement work begun. Test article versions of the product elements are subjected to special testing to qualify them for use in solution of the customer’s need.

1.2 Toward a more effective process

But in this process, is there not some way to characterize the activity called integration so that we may all agree on its meaning and upon which we can base a more effective and foolproof deployment of its power into our own system development programs? In this book we establish a premise that integration has a finite number of component parts, each uniquely definable, and follow the consequences of this premise to their ultimate conclusions. We will decompose integration work into its fundamental parts and integrate the results. Yes, we are going to apply the system engineering process to improving our understanding of this word and concept.

This book is a companion work to System Requirements Analysis, written by the same author, which covers the decomposition and requirements identification process occurring on the front end or down stroke of development programs. Integration work principally occurs on the tail end or up stroke of development programs. These two activities are separated by the creative design process that synthesizes requirements into design solutions which must be integrated into a system solution. These two system engineering methodologies, together with verification by testing and analysis, comprise the heart and soul of the systems approach to development of complex systems.

Some observers of the process expressed in these two books have concluded that it is only appropriate to apply it to grand systems with a Department of Defense (DoD) customer known for its deep pockets. The author believes the system engineering process is perfectly applicable to smaller scale developments as well as large ones and those oriented toward commercial customers as well as DoD and NASA customers. The Mars mission space transport system will include within it an on-board computer (many actually, but certainly one) that can be treated as a system by its supplier development team. That computer will include a power supply that could be treated as a system by its vendor design team. A company that develops and manufactures video recorders for the commercial market could apply these same principles as could a company whose product line is bean bags.

Some of the component parts of the process may be overkill for some combinations of product lines (like bean bags), customer bases, and degrees of difficulty in the development process or maturity of the corresponding technology needed. The skillful development team will select, or the experienced customer will insist on, the components that make sense for the particular program.

It is true that the process, in the past, has been primarily applied by the aerospace industry for large government customers interested in very complex systems. Much of the language used to express system engineering ideas and references for parts of the process are derived from this historical reality. The author has made a conscious effort to present the system integration process from a generic perspective but is himself a captive of the same history and may not have succeeded completely.

There is another side to this story, however. The author believes that people in firms in the commercial marketplace are little different from those in the DoD industry in their resistance to integrated and structured development. The systems approach to problem solving has been available for many years yet there are many managers, directors, and vice presidents in engineering organizations that support DoD and NASA customers who distrust it and avoid its successful application.

It is true that there are aerospace firms with very fine system engineeirng capabilities that they effectively apply with good results. The stories are many, however, and in agreement with some of the author’s own experiences in industry, of frustrated attempts to implement an effective system engineering process. The story goes something like this:

a. The customer will require in a request for proposal some evidence that a company has a system engineering capability. Typically this may take the form of a requirement that a system engineering management plan (SEMP) be submitted with the proposal. The company will write a credible SEMP with no intent to organize or work as described therein once the contract is awarded. Note that under MIL-STD-499A, which was the source of the SEMP requirement, the SEMP was not contractually binding.

b. When the contract is awarded to this firm, work begins using autonomous design groups interacting on an ad hoc basis. The customer becomes concerned that the company has neither a system engineering organization nor process and encourages the company to comply with their process requirements stated in the statement of work and the SEMP prepared by the contractor.

c. Finally, to get the customer off their backs after the design solution has been essentially determined, the company creates a system engineering function and assigns personnel to the program to accomplish a parallel system engineering process along the lines described in the SEMP. This team may be isolated from the design people and even told not to interact with them. They produce the standard set of system engineering products that may entail differences from the predetermined design solution and these products are essentially ignored.

d. At the earliest possible moment when the customer has been minimally satisfied that a systems approach has been applied, this group is disposed of.

Despite this history, even in some of our finest companies, some tremendous products have been developed that have served their customers (DoD and the general public) well. In some cases, not all, we will never know how much less these products would have cost or what other features or capabilities they may have had if a sound systems approach had been applied in their development. There appears to be a natural resistance to the systems approach driven by a human urge for power and control by those in functional management and by a human urge to belong to a group by the members of these organizations. The resulting autonomy of the functional organizations is the enemy of the systems approach on programs and it is alive and well in more places doing DoD work than one would think possible after decades of DoD insistence on an effective systems capability.

The point is that this same resistance, inspired by the same human motives, exists in commercial firms as well and prevents them from crossing the bridge sincerely looking for an effective organized product development approach which DoD has inspired but not been fully successful in obtaining from its contractors. Implementing an effective systems capability requires leadership from the top to impress everyone with the understanding that product success and a happy customer take priority over employee or management attitudes and company organizational dynamics. Product success results from customer value and that can be encouraged through an organized approach to problem solving called system engineering.

The author believes that the systems approach and happy employees are not mutually exclusive. The organizational structure and techniques encouraged in this book will provide an environment within which people, design engineers as well as system engineers, can excel in their profession. It will result in the imposition of the minimum set of constraints on the solution space within which the design community must seek a solution. It will result in the lowest cost and greatest value to the customer in the product they receive. Commercial companies that introduce appropriate elements of this process and educate their employees to perform them well will have an advantage over their competitors in terms of product cost, time to market, and product performance.

As we depart from a phase of history characterized by intense global military competition requiring increasingly sophisticated military systems, we will find that complex systems will be associated with a broader range of needs than in the past and the pace of development will be retarded from that of the past driven by a survival instinct. There will be a greater need to re-engineer old systems to upgrade their capabilities than to develop totally new systems pushing the state of the art in several directions at once. There will be a greater appeal to precedented systems than unprecedented ones involving a completely clean sheet of paper. Regardless of these changes, however, we are unlikely to discover a method for developing these new and modified systems that is more effective that the methods discussed in this book for they are based on the way we humans function.

1.3 Book organization

The book is composed of three parts. Part I, Chapters 1 through 5, explores the fundamentals of integration and offers a suggested organizational structure used throughout the book in other discussions. Part II, Chapters 6 through 10, focuses on process integration for the organization accomplishing a development program. This includes program planning, program tracking, discontinuity management, and organizing for concurrent development. Part III, Chapters 11 through 16, deals with product integration.

Part II is the province of system engineers who look at their profession as a management science the application of which allows them to get complex things done. People who do this work are commonly called project engineers and they are responsible for planning programs, setting up budgets, defining planned work in statements of work, and tracking programs to the planned budget and schedule. Part III is tuned to the system engineers who view their profession as an engineer solving complex product-oriented problems. These engineers work at the product interfaces and seek out inconsistencies between the system requirements and the current concept or design and within the overall work product of several different development teams.

System integration embraces both of these perspectives, process and product integration. While it is not uncommon for people with very different experiences to perform ...

Table of contents

• Cover
• Half Title
• Series Page
• Title Page
• Copyright Page
• Table of Contents
• Preface
• Author
• Acknowledgments
• Part I: The fundamentals
• Part II: Process integration
• Part III: Product integration
• Part IV: Closing
• Acronyms
• Index