System Integration

System integration consists of taking delivery of the implemented (system) elements which compose the system of interest (SoI), assembling these implemented elements together, and performing the verification and validation actions (V&V Actions) in the course of the assembly. The ultimate goal of system integration is to ensure that the individual system elements function properly as a whole and satisfy the design properties or characteristics of the system. System integration is one part of the realization effort and relates only to developmental items. Integration should not to be confused with the assembly of end products on a production line. To perform the production, the assembly line uses a different order from that used by integration.

Definition and Purpose

System integration consists of a process that “combines system elements (implemented elements) to form complete or partial system configurations in order to create a product specified in the system requirements” (ISO/IEC 15288 2008, 44). The process is extended to any kind of product system, service system, and enterprise system.

The purpose of system integration is to prepare the system of interest for final validation and transition either for use or for production. The integration consists of progressively assembling aggregates of implemented elements that compose the system of interest as architectured during design, and to check correctness of static and dynamic aspects of interfaces between the implemented elements.

The Defense Acquisition University provides the following context for integration: The integration process will be used... for the incorporation of the final system into its operational environment to ensure that the system is integrated properly into all defined external interfaces. The interface management process is particularly important for the success of the integration process, and iteration between the two processes will occur (DAU 2010).

The purpose of system integration can be summarized as:

1. Completely assemble the Implemented Elements to make sure that the Implemented Elements are compatible with each other.
2. Demonstrate that the aggregates of implemented elements perform the expected functions and performance/effectiveness.
3. Detect defects/faults related to design and assembly activities by submitting the aggregates to focused verification and validation actions.

Note: In the systems engineering literature, sometimes the term "integration" is used in a larger context than in the present topic. In this larger sense, it concerns the technical effort to simultaneously design and develop the system and the processes for developing the system through concurrent consideration of all life cycle stages, needs, and competences. This approach requires the "integration" of numerous skills, activities, or processes.

Principles

Boundary of Integration Activity

In the present sense, integration is understood as the complete bottom-up branch of the V cycle, including the tasks of assembly and the appropriate verification tasks. See Figure 1 below:

Figure 1. Limits of Integration Activities (Figure Developed for BKCASE)

The assembly activity joins together, and physically links, the implemented elements. Each implemented element is individually verified and validated prior to entering integration. Integration then adds the verification activity to the assembly activity, excluding the final validation.

The final validation performs operational tests that authorize the transition for use or the transition for production. Remember that system integration only endeavors to obtain preproduction prototypes of the concerned product, service, or enterprise. If the product, service, or enterprise is delivered as a unique exemplar, the final validation activity serves as acceptance for delivery and transfer for use. If the prototype has to be produced in several exemplars, the final validation serves as acceptance to launch their production. The definition of the optimized operations of assembly which will be carried out on a production line relates to the manufacturing process and not to the integration process.

Integration activity can sometimes reveal issues or anomalies that require modifications of the design of the system. Modifying the design is not part of the integration process but concerns only the design process. Integration only deals with the assembly of the implemented elements and verification of the system against its properties as designed.

During the assembly, it is possible to carry out tasks of finishing touches which require simultaneous use of several implemented elements (e.g., paint the whole of two parts after assembly, calibrate a biochemical component, etc.). These tasks must be planned in the context of integration and are not carried out on separate implemented elements. In any case, they do not include modifications related to design.

Aggregation of Implemented Elements

The integration is used to systematically assemble a higher-level system from implemented, lower-level ones (implemented system elements). Integration often begins with analysis and simulations (e.g., various types of prototypes) and progresses through increasingly more realistic systems and system elements until the final product, service, or enterprise is achieved.

System integration is based on the notion of an aggregate . An aggregate is a subset of the system made up of several implemented elements (implemented system elements and physical interfaces) on which a set of verification and validation actions is applied. Each aggregate is characterized by a configuration which specifies the implemented elements to be physically assembled and their configuration status.

To perform verification and validation actions, a verification and validation configuration that includes the aggregate plus verification and validation tools is constituted. The verification and validation tools are enabling products and can be simulators (simulated implemented elements), stubs or caps, activators (launchers, drivers), harness, measuring devices, etc.

Integration by Level of System

According to the vee (v) model , system definition (top-down branch) is done by successive levels of decomposition; each level corresponds to the physical architecture of systems and system elements. The integration (bottom-up branch) takes the opposite approach of composition (i.e., a level by level approach). On a given level, integration is done on the basis of the physical architecture defined during system definition.

Integration Strategy

The integration of implemented elements is generally performed according to a predefined strategy. The definition of the integration strategy is based on the architecture of the system and relies on the way the architecture of the system has been designed. The strategy is described in an integration plan that defines the configuration of expected aggregates, as well as the order of assembly of these aggregates in order to carry out efficient verification and validation actions (e.g., inspections and/or testing). The integration strategy is thus elaborated starting from the selected verification and validation strategy. See the System Verification and Validation topic.

To define an integration strategy, one or several possible integration approaches/techniques can be used. Any of these may be used individually or in combination. The selection of integration techniques depends on several factors, in particular, the type of system element, delivery time, order of delivery, risks, constraints, etc. Each integration technique has strengths and weaknesses which should be considered in the context of the system of interest. Some integration techniques are summarized in Table 1 below:

Table 1. Integration techniques (Table Developed for BKCASE)

Usually, a mixed integration technique is selected as a trade-off between the different techniques listed above, allowing optimization of work and adaptation of the process to the system under development. The optimization takes into account the realization time of the implemented elements, their delivery scheduled order, their level of complexity, the technical risks, the availability of assembly tools, cost, deadlines, specific personnel capability, etc.

Process Approach

Activities of the Process

Major activities and tasks performed during this process include:

1. Establish the integration plan (this activity is carried out concurrently to the design activity of the system) that defines:
   1. The optimized integration strategy: order of aggregates assembly using appropriate integration techniques.
   2. The verification and validation actions to be processed for the purpose of integration.
   3. The configurations of the aggregates to be assembled and verified.
   4. The integration means and verification means (dedicated enabling products) that may include assembly procedures , assembly tools (harness, specific tools), verification and validation tools (simulators, stubs/caps, launchers, test benches, devices for measuring, etc.), and verification and validation procedures .
2. Obtain the integration means and verification means as defined in the integration plan; the acquisition of the means can be done through various ways such as procurement, development, reuse, and sub-contracting; usually the acquisition of the complete set of means is a mix of these methods.
3. Take delivery of each implemented element:
   1. Unpack and reassemble the implemented element with its accessories.
   2. Check the delivered configuration, conformance of implemented elements, compatibility of interfaces, and ensure the presence of mandatory documentation.
4. Assemble the implemented elements into aggregates:
   1. Gather the implemented elements to be assembled, the integration means (assembly tools, assembly procedures), and the verification means (verification and validation tools, verification and validation procedures).
   2. Connect the implemented elements on each other to constitute aggregates in the order prescribed by the integration plan and in assembly procedures using assembly tools.
   3. Add or connect the verification and validation tools to the aggregates as predefined.
   4. Carry out eventual operations of welding, gluing, drilling, tapping, adjusting, tuning, painting, parametering, etc.
5. Verify each aggregate:
   1. Check the aggregate is correctly assembled according to established procedures.
   2. Perform the verification process that uses verification and validation procedures and check that the aggregate shows the right design properties/specified requirements.
   3. Record integration results/reports and potential issue reports, change requests, etc.

Artifacts and Ontology Elements

This process may create several artifacts such as:

1. Integrated System
2. Assembly Tool
3. Assembly Procedure
4. Integration Plan
5. Integration Report
6. Issue / Anomaly / Trouble Report
7. Change Request (about design)

This process handles the ontology elements of Table 2:

Table 2. Main ontology elements as handled within system integration (Figure Developed for BKCASE)

Note: verification and validation ontology elements are described in the Verification and Validation topic.

The main relationships between ontology elements are presented in Figure 2:

Figure 2. Integration Elements Relationships with Other Engineering Elements (Faisandier 2011)Reprinted with permission of © Alain Faisandier.

Checking and Correctness of Integration

The main items to be checked during the integration process:

• The integration plan respects its template.
• The expected assembly order (integration strategy) is realistic.
• No system element and physical interface set out in the system design document is forgotten.
• Every interface and interaction between implemented elements is verified.
• Assembly procedures and assembly tools are available and validated prior to beginning the assembly.
• Verification and validation procedures and verification and validation tools are available and validated prior to beginning the verification.
• Integration reports are recorded.

Methods and Techniques

Several different approaches are summarized above in the section "Integration Strategy" that may be used for integration, yet other approaches exist. In particular, important integration strategies for intensive software systems include vertical integration, horizontal integration, and star integration.

Coupling matrix and N-square diagram. One of the most basic methods to define the aggregates and the order of integration would be to use N-Square diagrams (Grady 1994, 190).

In the integration context, the coupling matrices are useful for optimizing the aggregate definition and verification of interfaces:

• The integration strategy is defined and optimized by reorganizing the coupling matrix in order to group the implemented elements in aggregates, thus minimizing the number of interfaces to be verified between aggregates (see Figure 3).

Figure 3. Initial arrangement of aggregates on the left; final arrangement after reorganization on the right (Figure Developed for BKCASE)

• When verifying the interactions between aggregates, the matrix is an aid tool for fault detection. If by adding an implemented element to an aggregate an error is detected, the fault can be either related to the implemented element, to the aggregate, or to the interfaces. If the fault is related to the aggregate, it can relate to any implemented element or any interface between the implemented elements internal to the aggregate.

Application to Product Systems, Service Systems, and Enterprise Systems

As the nature of implemented system elements and physical interfaces is different for these types of systems, the aggregates, the assembly tools, and the verification and validation tools are different. Some integration techniques are more appropriate to specific types of systems. The Table 3 below provides some examples:

Table 3. Different Integration Elements for Product, Service, and Enterprise Systems.

Practical Considerations

Major pitfalls encountered with system integration are presented in Table 4:

Table 4. Major Pitfalls with System Integration.

Major proven practices encountered with system integration are presented in Table 5:

Table 5. Proven Practices with System Integration.

References

This article relies heavily on limited sources. Reviewers are requested to identify additional sources.

Citations

DAU. February 19, 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).

Primary References

INCOSE. 2010. Systems Engineering Handbook: A Guide for Systems Life Cycle Processes and Activities. Version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.

NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

Additional References

DAU. February 19, 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.

Gold-Bernstein, B., and W.A. Ruh. 2004. Enterprise integration: The essential guide to integration solutions. Boston, MA, USA: Addison Wesley Professional.

Grady, J.O. 1994. System integration. Boca Raton, FL, USA: CRC Press, Inc.

Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight 12(4):59-63.

Jackson, S. 2010. Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions. Hoboken, NJ, USA: John Wiley & Sons.

Reason, J. 1997. Managing the Risks of Organisational Accidents. Aldershot, UK: Ashgate Publishing Limited.

---

<- Previous Article | Parent Article | Next Article ->