System Integration

Introductory Paragraph(s)

System Integration

Introduction, Definition and Purpose

Introduction –System Integration consists of taking delivery of the implemented Components (system elements) which compose the System-of-Interest, assembling these Components together, and performing the Verification 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 specified requirements (design characteristics) of the system. System integration is one part of the realization effort and relates only to developmental items. Integration has 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 the one for integration.

Definition and Purpose – System Integration consists of a process that “combines system elements to form complete or partial system configurations in order to create a product specified in the system requirements.” (ISO/IEC 15288 2008, p. 44). The process is extended to any kind of product system, service system and enterprise system. System integration purpose is to prepare the System-of-Interest ready for final validation and transition either for use or for production. The integration consists of assembling progressively aggregates of Components (system elements, sub-systems) that compose the System-of-Interest as architectured during design, and to check correctness of static and dynamic aspects of interfaces between the Components. 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 February 19, 2010)

The purpose of system integration can be summarized as: (1) completely assemble the System-of-Interest to make sure that the Components are compatible with each others; (2) demonstrate that the aggregates of Components perform the expected functions and performance/effectiveness; (3) detect defects/faults related to design and assembly activities by submitting the aggregates to focused Verification Actions.

Note: In the systems engineering literature, sometimes the term "integration" is used in a larger acceptation 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 7.

Limits of integration activities

The assembly activity joins together and physically links the Components. Each Component 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 endeavours 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 Components and verification of the system against its characteristics as designed.

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

Aggregation of Components

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

System integration is based on the notion of Aggregate. An Aggregate is a subset of the system made up of several physical Components and Links (indiscriminately system elements or sub-systems) on which a set of Verification Actions is applied. Each aggregate is characterized by a configuration which specifies the components to be physically assembled and their configuration status.

To perform Verification Actions, a Verification Configuration that includes the Aggregate plus Verification Tools is constituted. The Verification Tools are enabling products and can be simulators (simulated components), stubs or caps, activators (launchers, drivers), harness, measuring devices, etc.

Integration by Level of System

According to the V model (see Figure 2), System Definition (top-down branch) is done by successive levels of decomposition; each level corresponds to physical architecture of components (systems and system elements). The integration (bottom-up branch) consists in following the opposite way of composition level by level.

On a given level, integration is done on the basis of the physical architecture defined during System Definition.

Integration Strategy

The integration of Components 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, the order of assembly of these Aggregates in order to carry out efficient Verification Actions (for example, inspections and/or testing). The integration strategy is thus elaborated starting from the selected Verification & Validation strategy (see section xxxxxx Verification & Validation Processes).

To define an integration strategy one can use one or several possible integration approaches / techniques. Any of these may be used individually or in combination. The selection of integration techniques depends of several factors, in particular the type of system, 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 hereafter. See section 3.4.4.3.5 for some others.

Global integration - Also known as "big-bang integration"; all the delivered components are assembled in only one step.

• This technique is simple and does not require simulating the components not being available at that time.
• Difficult to detect and localize faults; interface faults are detected late.
• Should be reserved for simple systems, with few interactions and few components without technological risks.

Integration "with the stream" - The delivered components are assembled as they become available.

• Allow starting the integration quickly.
• Complex to implement because of the necessity to simulate the components not yet available. Impossible to control the end to end "functional chains"; so global tests are postponed very late in the schedule.
• Should be reserved for well known and controlled systems without technological risks.

Incremental integration - In a predefined order, one or a very few components are added to an already integrated increment of components.

• Fast localization of faults: a new fault is usually localized in lately integrated components or dependent of a faulty interface.

• Require simulators for absent components. Require many test cases : each component addition requires the verification of the new configuration and regression testing.

• Applicable to any type of architecture.

Subsets integration - Components are assembled by subsets, and then subsets are assembled together (a subset is an aggregate); could be called "Functional Chains Integration".

• Time saving due to parallel integration of subsets; delivery of partial products is possible. Requires less means and fewer test cases than integration by increments.

• Subsets shall be defined during the design.

• Applicable to architectures composed of sub-systems.

Top-down integration - Components or aggregates are integrated in their activation or utilization order.

• Availability of a skeleton and early detection of architectural faults; definition of test cases close to reality; re-use of tests data sets possible.

• Many stubs/caps need to be created; difficult to define test cases of the leaf-components (lowest level).

• Mainly used in software domain. Start from the component of higher level; components of lower level are added until leaf-components.

Bottom-up integration - Components or aggregates are integrated in the opposite order of their activation or utilization.

• Easy definition of test cases; early detection of faults (usually localized in the leaf-components); reduce the number of simulators to be used. An aggregate can be a sub-system.

• Test cases shall be redefined for each step; drivers are difficult to define and realize; components of lower levels are "over-tested"; does not allow to quickly detecting the architectural faults.

• Mainly used in software domain and in any kind of system.

Criterion driven integration – The most critical components compared to the selected criterion are first integrated (dependability, complexity, technological innovation, etc.). Criteria are generally related to risks.

• Allow to test early and intensively critical components; early verification of design choices.

• Tests cases and tests data sets are difficult to define.

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

Process Approach

Purpose and Principle of Approach

The purpose of the System Integration Process is to assemble the Components and Links between the components (systems and system elements) in order to obtain the system that is compliant with its physical and functional architecture design.

The activities of the Integration Process and those of the Verification Process fit into each other.

The process is used by any system of any level of the decomposition of the System-of-Interest. It is used iteratively starting from a first aggregate of Components till the complete system; the last "loop" of the process results in the entirely integrated system.

The generic inputs are: the elements of the Functional Architecture (functions, functional interfaces: inputs outputs and control flows); the elements of the Physical Architecture (components, physical interfaces: links and ports); the specified requirements applicable to the design of the concerned system.

The generic outputs are: the Integration Plan containing the integration strategy; the integrated system; the integration means (enabling products as tools and procedures); integration reports, eventually issue/trouble reports and change requests about design.

The outcomes of the Integration Process are used by the Verification Process and by the Validation Process.

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 design activity of the system) that defines:
   1. The optimized integration strategy: order of aggregates assembly using appropriate integration techniques.
   2. The Verification 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 Tools (simulators, stubs/caps, launchers, test benches, devices for measuring, etc.), Verification 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, sub-contracting; usually the acquisition of the complete set of means is a mix of these ways.
3. Take delivery of each component:
   1. Unpack, and reassemble the component with its accessories.
   2. Check the delivered configuration, conformance of component, compatibility of interfaces, the presence of mandatory documentation.
4. Assemble the components into aggregates:
   1. Gather the components to be assembled, the integration means (Assembly Tools, Assembly Procedures), and the verification means (Verification Tools, Verification Procedures).
   2. Connect the components on each others to constitute aggregates in the order prescribed by the Integration Plan and in Assembly Procedures using Assembly Tools.
   3. Add or connect the Verification 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 Procedures and check that the aggregate shows the right design characteristics / specified requirements.
   3. Record integration results or 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)

The main relationships between ontology elements are presented in Figure 8.

Checking and Correctness of Integration

The main items to be checked during the integration process:

• The Integration Plan respects it's template
• The expected assembly order (integration strategy) is reaklistic
• No component and link set out in the System Design Document is forgotten
• Every interface and interaction between components is verified
• Assembly Procedures and Assembly Tools are available and validated prior begining the assembly
• Verification Procedures and Verication Tools are available and validated prior begining the verification
• Integration reports are recorded

Integration methods and techniques

Several different approaches are summarized in section 3.4.4.2 that may be used for integration. Other ones exist, in particular for intensive software systems such as Vertical Integration, Horizontal Integration, Star integration described below. Vertical integration is the method used to combine subsystems according to their functionality by creating functional entities also referred to as silos. (Lau 2005, 52) Integration can be performed quickly and will involve only the necessary stakeholders. This speed and limited external involvement generally allow vertical integration to be lower in cost short-term. However, cost-of-ownership may be substantially higher than seen in other methods, because another functional entity must be created for new or enhanced functions. Reusing subsystems to create new functions or improve existing functions is not possible. (Lau 2005, 52)

Horizontal integration or enterprise service bus (ESB)

The method in which a specialized subsystem is dedicated to communication between other subsystems. (Lau 2005, 52) This reduces the number of interfaces, because each subsystem will have one interface: the one linking it to the ESB. The ESB is capable of translating data from one subsystem into a format that can be utilized by another subsystem. This generally cuts integration costs and provides flexibility. It is possible to replace a subsystem with another subsystem that provides similar functionality, but that may use different interfaces. This is completely transparent to all other subsystems. In this instance, the only action required is to implement the new interface between the ESB and the new subsystem. (Lau 2005, 52) The cost of horizontal integration can be misinterpreted or incorrectly estimated, however, if the costs of intermediate data transformation or of shifting responsibility over business logic are not taken into account.

Star integration

An integration method where each subsystem is interconnected to each of the remaining subsystems. When observed from the perspective of the subsystem that is being integrated, the connections are reminiscent of a star. The cost varies, depending upon the interfaces that are exported by subsystems. When the subsystems are exporting similar or heterogeneous interfaces, integration costs can substantially rise. Time and costs needed to integrate the systems increase exponentially when adding additional subsystems, particularly if these subsystems utilize novel interfaces. From the feature perspective, this method often seems preferable, due to the extreme flexibility of the reuse of functionality. (Lau 2005, 52)

Coupling matrix and N-square diagram

One of the most basic methods to define the aggregates and the order of integration would be the use of N-Square diagrams. Jeff Grady’s - System Integration – page 190 – 1994, CRC Press - Boca Raton, Florida, US

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 components in aggregates minimizing the number of interfaces to be verified between aggregates (see Figure 9).

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

Application to Product systems, Service systems, Enterprise systems

As the nature of implemented Components and Links is different for these types of systems, the Aggregates, the Assembly Tools, the Verification Tools are different. Some integration techniques are more appropriate to types of systems. The following table provides some examples.

Practical Considerations

Pitfalls

1. The experience shows that the components always do not arrive in the expected order and the tests never proceed or result as foreseen; so the integration strategy should allow a great flexibility.
2. The "big-bang" integration technique is not appropriate for a fast detection of faults. It is thus preferable to verify the interfaces progressively all along the integration.
3. The preparation of the integration activities is planned too late in the project schedule, typically when first components are delivered.

Proven practices:

1. The development of Assembly Tools and Verification Tools can be as long as the system itself. It should be started as earlier as possible as soon as the preliminary design is nearly frozen.
2. The development of integration means (Assembly Tools, Verification Tools) can be seen as enabling systems, and so using System Definition and System Realization Processes as described in this SEBoK, and managed as projects. These projects can be led by the project of the corresponding System-of-Interest, but assigned to specific system blocks, or can be subcontracted as separate projects.
3. A good practice consists in gradually integrating aggregates in order to detect faults more easily. The use of the coupling matrix applies for all strategies and especially for the bottom up integration strategy.
4. The integration process of complex systems cannot be easily foreseeable and its progress control difficult to observe. This is why, it is recommended to plan integration with specific margins, using flexible techniques, integrating sets by similar technologies.
5. The Integration Responsible should be part of the Design Team.

Primary References related to the topic

INCOSE. 2010. INCOSE systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.

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

Additional References and Readings related to the Topic

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

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

HITCHINS, D. 2009. What are the General Principles Applicable to Systems? Insight. International Council on Systems Engineering.

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.

[Go to discussion page]