U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.6.2 Integration [Sub-system and System Level Integration]



Integration is the process of successfully combining hardware and software components, sub-systems, and systems into a complete and functioning whole.


Integration is an iterative process:

  • taking hardware and software components
  • forming them into complete sub-system elements
  • combining the sub-system elements into larger combined sub-systems
  • combining all sub-systems into the final system

Integration planning starts when the project activities are first defined. The next major input occurs when the sub-systems are identified during the high-level design and project architecture step. Finally, integration is performed when the hardware and software components are developed and delivered by the development team. Integration and verification are closely linked processes in which one follows the other until the entire system is ready for operational deployment.

A complex project may need a written Integration Plan. Integration activities are driven by:

  • system requirements
  • internal interfaces within the system
  • external interfaces to legacy systems and the deployment strategy

Integration activities are performed iteratively along with verification.


Shows the flow for Phase [3] Task 2, Integration Process. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.



Concept of Operations describes the way the system is to operate and will assist in the verification and integration effort.

System and Sub-system Requirementscontain the requirements for the sub-systems / systems.

High Level Design [project architecture] defines the integration activities to be performed.

Component Level Detailed Design contains the design constraints for the sub-systems/systems to be integrated.

Deployment Strategy defines when and where the sub-systems are to be grouped and deployed.

Developed hardware / software components and sub-systems have completed integration and are ready for the next level of verification.


Project Plan/SEMP establishes a high level description of the systems engineering plan for integration.

Configuration Management Plan sets the configuration controls needed during integration.


Stakeholder involvement is needed to assist with integration with external systems and devices.


Integration Master Plan establishes the goals and high level approach to integration.

Integration Plan [optional] documents the high level plan and process for integrating the system. This is part of the Project Plan/System Engineering Management Plan [SEMP].

Integrated sub-systems / system means they are ready for verification.

Process Activities:

Plan integration activities:

Planning includes the sequence in which the various components of the system should be integrated, the needed resources, schedule, and coordination activities [if multiple development teams are involved], and the documented plan itself. A number of factors influence the integration sequence, including the order in which components and sub-systems are produced by the development team[s].

Each integration step should produce a product that implements a related set of functionality. For example, an operator interface may be integrated with a loop data collection function before the loop data function is integrated with an incident management function.

Define integration activities:

At the high level design [project level architecture] integration activities are defined. Sub-systems, internal interfaces, and external interfaces are defined. They are the key points for integration. Also, at the high level design, the number of integration/verification cycles are defined.

Perform integration activities:

The first step is to ensure that the integration team has access to the resources needed to support the planned integration step. Special attention has to be paid to resources that come from outside integration team's organization. These could include: support from the developers or manufacturers, support from other agencies with an external interface, a testing environment [e.g. workstations, communications, and interface simulators.], and, of course, the various sub-systems to be integrated.

As integration proceeds, issues are monitored through periodic reviews as follows:

  • is progress being made in accordance with the schedule
  • are the problems are being resolved in a timely manner
  • are verify requirements changes are being addressed in accordance to the Configuration Management Plan
  • are resources being made available when needed
  • is there adequate coordination between development teams

As the cycle of integration and verification is repeated, lessons learned during a verification step may have to be fed into the next round of integration. Integration should be complete enough that subsequent verification proceeds with minimum disruption.

Illustrates where Integration occurs in the Vee Development Model. The integration is planned in the Systems Engineering Management Plan section and is defined in the High-Level Design (Project Architecture) Subsystem Requirements section. Integration is performed in the Unit Testing, Subsystem Verification, and System Verification and Initial Deployment sections.

Where does Integration take place in the project timeline?

Is there a policy or standard that talks about integration?

FHWA Final Rule does not specifically mention integration as one of the required systems engineering analysis activities. EIA 731 and CMMI have identified best practices for integration.

Which activities are critical for the system's owner to do?

  • Determine the need for a written Integration Plan
  • Review and approve the Integration Plan, if one is needed
  • Manage the timely acquisition of resources needed to support integration
  • Track the progress of integration with respect to the project schedule. Intervene if the progress falls behind the schedule

How do I fit this step to my project? [Tailoring]

There are a number of factors which make a project complex. The same factors that influence other steps in the systems engineering process also influence the integration process.

Integration of sub-systems with external interfaces is nearly always required.

The major impact on tailoring the integration process is the degree of formality needed to verify compliance with requirements to stakeholders. The simpler the system, the smaller the project team and the fewer the number of external stakeholders [stakeholders with systems that interface with the target system], the less formal the integration process needs to be.

What should I track to reduce project risk and to get what is expected? [Metrics]

  • The number of times failures are detected during integration is a good indicator of the quality of the development effort
  • The number of times a later stage of integration turns up a problem that should have been detected in an earlier stage of integration is a good indicator of the quality of the integration effort
  • The number of times problems are not found in integration but are discovered during verification is an even stronger indicator of the quality of the integration effort.

Checklist: Are all the bases covered?

check Are integration activities included in the master project schedule?
check Does the plan for integration and verification support the strategy for deployment?
check Based on project complexity, is a written Integration Plan required?
check Are the external systems needed to support integration available, or does the interface need to be simulated?
check Have the components to be integrated been placed under configuration control?
check Are the development teams available to promptly fix problems uncovered during integration?

Are there any other recommendations that can help?

The importance of a good strategy and verification of design:

Tip.Recommendation.Develop a good integration strategy: A successful integration process is based on a sound strategy which will give it direction and completeness. This same strategy will be needed to guide the verification and initial deployment activities. This strategy is based on a set of goals that were established early in the planning stages of the project. These goals answered the following questions:

  • In what order does one need to deploy these capabilities in order to provide useful operational capabilities at each step?
  • How does one want to evolve the operational capabilities at a location in order to provide increasingly useful operational capabilities?
  • What are the funding limitations?

Of course that last goal, spending the available funds in the most effective manner, is usually the hardest to solve. Since these goals are related to deployment, this subject will be revisited in Chapter 3.6.4. Nevertheless, the integration plan, as well as the design, must be fashioned to meet these deployment goals.

As has been stated before, "integration is a more informal activity than verification". As such, the preparation of detailed plans and procedures is generally not required. In fact, if such structure is felt to be necessary, the procedures used for subsequent verification can also be used as part of the integration activity. Thus, the verification dry-run [see the verification chapter] could also be seen as part of the integration effort.

Verification of design:

Integration is more than a verification of requirements; it is also a verification of the design. It explores the details of both the hardware and software. It needs, for instance, to look at hardware and software interfaces at a much lower level than just exercising the functional requirement.

Generally, this informal integration approach is effective since it avoids the costs of more formal documentation. Still, it needs to be carefully monitored. It needs adequate project support. It also needs the right people on the integration team.

A closer look at integration and verification and levels of integration

Integration and verification are iterative processes with each other. Integration puts a sub-system [or system] together from components [and/or other sub-systems], and informally assures that everything is working as it should in accordance with the requirements. Verification formally tests the assembled system [or sub-systems] to show that all applicable requirements are met. The figure shows this cycle and how it is repeated until the entire system can be accepted.

Levels of integration means that the levels of integration needed for a system will match the number of levels of the system hierarchy. For example, a traffic control system would have the following 3 levels of hierarchy.

  • the component level [the loops and field controllers] would be the first level of integration
  • the sub-system level [field controllers with field masters] would be the next level of integration
  • the system level [host with the field masters and field controllers] would be the final level integration.

More complex systems may have additional levels of hierarchy and integration. For example, in regional ITS, the traffic control system example above may need to integrate with a freeway ramp metering system for coordination. This would represent a fourth level of integration and so on.

Flow shows that unit tested components are integrated and then verified. This process continues until the entire system has been sucessfully integrated and verified.

Figure 3-13 Integration and Verification are Iterative

Related Template Checklist  


Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000