Sie sind auf Seite 1von 11

Looking Forward Engineering Systems

Integration
Dr. Meir Tahan
Ort Braude College, Karmiel, Israel
tahanm@braude.ac.il

Abstract. Engineering systems integration involves dealing with a multiplicity of challenges.


Different disciplines must be balanced, the work of several teams must be coordinated, and
the issue of units that are necessary but not available on time must be handled; special test
equipment must be designed, hubs and stubs must be prepared; and risks that are liable to
occur during integration must be assessed and prevented to name just a few of the tasks.
All these problems and difficulties result in schedule delays and unplanned expenses.
We present a structured methodology for building an integration preparation plan and
thereafter guiding the actual integration. The methodology is based on the "V" model for
systems engineering. The left side of the "V" represents the design stage and the right side
represents the integration stage. The looking forward methodology follows the
development steps and at each step looks forward to the relevant integration step, anticipating
what may be required for successful integration. This action creates versatile integration tools
that are flexible enough to absorb unexpected variations in the project.
1.0 Introduction
Integration is a key process in the wider task of verification and validation of a systems
technical, functional and HMI (Human Machine Interface) requirements. During this process
an integration team integrates individual units until the complete system is created. The
interface between the units and their performance within the complete system are tested,
verified and validated.
The integration process has to overcome many challenges, among which are:
1. Units may arrive in a different order than the one planned.
2. Unexpected project risks may emerge during integration.
3. Because the integration process takes place at the end (or almost at the end) of the
overall process:
a. It is sometimes neglected during the project planning stage.
b. It becomes very difficult and expensive to make changes at such a late stage.
c. It is too late to build integration-specific tools.
d. The integration stage has to compensate for project delays.
4. Multidisciplinary technical issues.
5. Difficulties with recovery mechanisms.
The integration process is a technical and managerial challenge. The question is how can
engineers better prepare for the integration and successfully meet the challenge it represents.
The paper suggests a looking forward methodology based on the well-known "V" model
(INCOSE) for systems engineering.
The paper is organized as follows: Section 2 presents a brief summary of systems engineering
challenges. Section 3 offers a brief summary of the methodology we propose for creating a
robust integration process plan. The last section is a summary.

2. Integration Challenges

2.1 General
Engineering systems integration is inherently a process laden with uncertainties, problems
and difficulties (Browning 1996 pp. 787793; Buus et al. 1991 pp. 656666; Power et al.
1996 pp. 3 9; Tahan and Ben Asher 2008 pp. 165185). The following section reviews
some common integration challenges.

Built-in Integration Issues. Engineering projects start with the customers needs and end
with the satisfied customer (successful validation). The integration stage is the one just before
the customer validation stage.
The time between when the customer needs are specified and the integration is executed can
be a few months to many years, depending on the project complexity. During this period
many things may be changed:
The customer needs
The customer representative
The customer may understand the needs in a new and different manner
The technology may be changed.
Although so many changes are possible, the project still has to meet the customer needs as
they exist when the integration stage begins. A well-managed project keeps pace with the
customer and the technology, and the integration group should take any and all changes into
consideration. This mission is impossible if the integration tools are not flexible enough.
Design Factor Challenge. System design involves coordinating many groups, a complicated
task. The role of the integration team at the system design stage is organization dependent.
Some organizations expect the integration group to be involved at this stage; others do not.
Usually the unit design is done by the professional group with the involvement of the systems
engineering team. The integration group has little to no influence at all on what is decided at
this stage.
Given that the involvement of the integration group is usually insignificant at this stage, some
important integration issues such as interface, RFI/EMI compatibility and special signals
treatment are often not given the attention they deserve. Furthermore, the system testability,
test points and excitation points should be available to the integration group. Lack of input
from the integration group regarding the design may cause these points to be overlooked and
result in a difficult integration.

Risk Factor Challenge. During project development, risks are identified and mitigation
actions are taken. Unfortunately, despite the preventative actions, not every risk can be
anticipated and some risks will emerge at the integration stage. It may also be that some
mitigation actions were not effective so the risk may appear during integration. A risk that
appears during integration which is a relatively late stage is very hard to resolve.

Schedule Factor Challenge. In many cases the development stage may take longer than
planned. As a result, units are available for integration in a different order than planned.
Some integration steps require resources such as test equipment, tools and special
laboratories. Sometime these resources are not available on time. Alternatively, the
integration stage may run into problems and take longer than planned. The integration step is
one of the projects last activities. At this stage making a change in the system or in the test
equipment built for the integration is almost impossible without affecting the project
schedule. The project due time is usually rigid, thus the integration team has to compensate
for project delays.

Cost Factor Challenge. As mentioned above, the integration stage is one of the last project
activities. At this stage the cost of making any changes or not following the plan is very high
since the project due time is rigid. Any equipment or tool that was not built in advance and
that was found at the integration stage to be absolutely required will be an unplanned-for
expense since the project needs it urgently.

Employee Factor Challenge. At the development stage, integration seems so far away that
the tendency is to postpone dealing with it. The development stage seems more creative, thus
more attractive, and employees generally prefer to concentrate on the design. Planning proper
integration requires a lot of experience; however, usually employees who successfully
integrate a project are promoted, taking with them their insight, knowledge and skills which
means that the next integration project will, in many respects, have to start from square one.

Multidisciplinary Fields Factor Challenge. Today, most projects involve multidisciplinary


fields such as electronics, mechanics, control, software, physics, optics, aerodynamics and
much more. The integration team must have enough understanding of the fields involved in
the project in order to find and solve integration problems. A deep understanding would, of
course, be preferred but it is difficult to find people who have deep knowledge of more than
one field. Thus multidisciplinary projects suffer from a lack of central control, which may
result in some technical fields not being dealt with and difficulties with a recovery
mechanism.
Outsourcing Factor Challenge. Projects sometime require input from a field of knowledge
that does not exist in the organization, and therefore, it is outsourced. Outsourcing contracts
are usually very rigid and very difficult to change after the contract is signed. The external
supplier is not usually aware that he is expected to participate during the integration step.
Special effort is required to define the integration requirement at the contract stage.

COTS Factor Challenge. Commercial off-the-shelf units are units with almost zero degrees
of freedom for system developers. System developers usually do not have an exact
mathematical model of the unit they are handling. Accordingly, when a problem arises during
integration, the integration team has no internal tools to help explore why the difficult
developed.

Integration Challenges Summary. The integration process presents a lot of difficulties


and challenges. The many changes during the project life and the problems that appear from
time to time force the integration group to improvise. The ability to improvise is an important
characteristic for the integration team to have but relying on it as methodology would be a
catastrophe for any project. In Section 3 we propose a methodology, based on the well-known
"V" model for systems engineering, which leads the integration team and the systems
engineering team during system development to create a testable system and flexible test
equipment. The proposed methodology cannot guarantee a smooth integration process but it
can help create flexible tools during the development stage that, in the integration stage, the
integration team can modify and adapt to fit the changes or use to solve problems that may
arise.

3. Looking Forward Integration Methodology

3.1 The Methodology Basics


Figure 1 shows one interpretation of the "V" model for systems engineering. The "V"
model describes the development sequence (basically, a timeline) in a symmetrical "V"
shape. The development sequence starts with the requirements analyses during which the
systems engineering team tries to understand the customer needs and the process ends with
the customer validation of the system. The left side of the "V" represents the system
development while the right side represents the system integration. The symmetrical "V"
shape presentation helps highlight the relationship between a specific development stage and
its counterpart in the integration stage.
Figure 1. Basic "V" Model

The looking forward methodology claims that since any development stage has a related
integration and testing (Verification or Validation) stage, the integration team must look to
the other side of the "V" and find out what the testing (Verification or Validation)
requirements for the current stage are and how these are to be achieved. The same is to be
done for the required interfaces.

3.2 Actions at the Requirements Analyses Stage

At this stage the project team has a little knowledge regarding the system, yet some useful
actions can be taken to improve the system integrability. Since at this stage the systems
engineering group is analyzing the project requirements, "the system in its environment"
diagram is one of its products. From this simple diagram the integration group can produce:
1. "Black Box" tests (Functional tests; can be used for verification and validation)
2. An outline for an N2 interface chart
3. An IRD (Interface Requirements Document) for the external interface, which by the end
of the project will be transformed into the ICD (Interface Control Document).
The black box tests are obvious, given that the integration group really does not know what
will be in the system (actually nobody knows) and the system can be tested as a "Black Box"
only. By preparing "Black Box" tests, the integration group can find and determine the
requirements for test equipment, some of the requirements for special tools, and special
laboratory requirements.
An outline for the N2 interface chart can be derived easily from "the system in its
environment" diagram. This is the first step in the system interface development and can be
used for writing the IRD.
The IRD at this stage reveals problems in misunderstanding the external interfaces
(electronic, mechanical, optical). This document becomes one of the SRR (System
Requirements Review) documents. The project team and the customer examine the IRD in
order to be sure that interfaces are completely right and fit the customer needs.
Though little information about the project is available and known at this stage, meaningful
actions can be taken. The integration group can produce requirements for external interfaces
and test equipment.

3.2 Actions at the System Design Stage


General. At the system design stage the systems engineering group generates a lot of
information about the system building blocks (sub-systems and units) and the relationships
among them. It is at this stage that the system block diagram is created and the contribution
of the integration group is critical. Once the system block diagram is ready, the integration
group can:
1. Design the internal system interfaces and complete the IRD;
2. Define the required "White Box" tests (constructional tests; usually used for verification)
for the system integration;
3. Design the testing interfaces (excitation points and test points);
4. Define the required test equipment and test tools for the integration;
5. "Whiten" the "Black Box" tests;
6. Define the "Black Box" tests that could not be defined in Step 5;
7. Define "Black Box" tests for the sub-systems and units;
8. Define testability requirements for the sub-systems and units;
9. Choose the integration concept;
10. Define the required test equipment and test tools for each integration step;
11. Plan the integration.

System Interface Design. As mentioned above, the system block diagram is known at this
stage and the integration team can start working on the internal interface design. The idea of
having the integration group work as the interface designers decreases the chances of
mismatching the interfaces during integration. Of course, the integration group must follow
the design to make sure that it is implemented. The system IRD should be prepared at this
stage as well.

System Level "White Box" Tests. The system block diagram and the system internal
interface are defined at this stage. The integration group can design the integration
constructional tests (verification tests), the so-called "White Box" tests. Design of the "White
Box" tests for the system at this stage reveals the required test equipment and required testing
interfaces.

Testing Interfaces. Integration groups sometime suffer from the absence of a test point and
excitation points. A test point is required in order to follow the signal flow in the system.
Excitation points are required to inject signals into the system units in order to test the
response of a unit or several units to this input. Knowing what the test requirements are, it is
possible to define the testing interface requirements and design them. Ensuring that the
design includes testing interfaces will provide the flexibility to create a new test if a problem
arises during integration.

System Integration Testing Equipment. After the definition of the testing requirements and
the testing interfaces, the test equipment can be defined. Lack of testing equipment during
integration can be destructive to the integration process. Designing the integration test
equipment at an early stage is good since this means there is enough time to design reliable
test equipment. Special care should be taken to ensure that this test equipment is flexible
since the requirements of the project may change during its development.

"Whitening" the "Black Box" Tests. Testing the system as a "Black Box" probably reveals
most system problems/failures. At this point the integration team finds out the reason for any
failure. Whitening the "Black Box" tests by adding essential test points and excitation points
at the system level will be helpful during the preparations for the acceptance tests and during
the acceptance test.

Completion of the "Black Box" Test Requirements. The systems engineering group
sometimes adds features to the system that are not in the requirements. Some "Black Box"
tests are hard to define at the requirements stage. The addition of test points may influence
the tests. For these reasons, a review and modification of the "Black Box" tests is required.

Sub-system and Unit "Black Box" Test Requirements and Testability. The systems
engineering team defines the sub-system and the units. The systems integration team can
define the "Black Box" tests and the requirements for testability. The "Black Box" sub-
system and unit test requirements are prepared in the same way and for the same reasons as
the system level tests. The testability requirements at this stage happen earlier since defining
the sub-system requirements is done by an internal team and more knowledge is now
available.

Integration Concept Decision. There are many integration concepts (Sommerville 2001 pp.
459462.):
1. Big bang integration Integrates all units in one step
2. Incremental Integration Step by step integration using completed units
a. Adaptive Integration Integrates units as they become available for integration
b. Bottom-up/Architecture Based Integration by logical order
c. Top-Down Building of a surrogate system, which is then replaced by available units
3. Functional/Phased Integration Integration of the whole function
4. Spiral Integration/Risk Oriented Partial integration with non-completed units
5. Neighborhood Integration
a. Geographical Neighborhood Integrates the units in the same geographical location
b. Interface Neighborhood First integrates the units that have more interface
connections
6. Parallel Integration Dividing the system into several sub-systems and integrating them
in parallel. Then integrating the integrated sub-systems to a complete system.
7. Plug & Play Integration Open system integration The design must follow some rules
and as you plug the unit in, it integrates itself and is ready to use (in the same way in
personal computers that units plug themselves in).
Each concept has advantages and disadvantages. Parallel integration shortens the integration
but requires a multi-team. Top-down integration is very convenient but requires an expensive
surrogate system. Spiral integration reduces risks but a lot of effort is expended working with
not completely finished units.
Only parts of each theoretical concept should be used. The integration team must not use one
approach from the beginning to the end of the integration process. Choosing the right
approach requires a lot of integration experience. This article recommends examining some
key factors in order to choose the right integration concept for the project.
1. Projects with more than one dominant discipline (a dominant discipline exists in many
units). Parallel integration is recommended according to the disciplines involved. For
example, an electronic washing machine has two dominant disciplines, electronics and
mechanics. A mechanical integration team is the best team for testing the machine
vibration, noise sources, etc. An electronics integration team is the best one to handle the
electronic control of the machine.
2. If it possible and not expensive to build a surrogate system, then a top-down methodology
is excellent. Using the above example of the washing machine, top-down mechanical
integration is almost impossible but for the electronics it may be quite useful because a
computer interface with limited software may control the washing machine units.
Airborne and naval systems should be integrated in a dynamic environment, which is not
practical. Since for these kinds of systems, simulators and surrogates units are built
anyway, top-down integration should be considered.
3. When many functions of the system are subject to high risk, spiral integration should be
an option. When small amounts of functions are subject to high risk, functional
integration with management priority given to the risky functions should be considered.
4. Consider the geographical distance when choosing the integration concept.
5. Consider constraints such as safety, special laboratories, and customer requirements when
choosing the integration concept. For example, explosives should be integrated last in a
bunker or special laboratory.

Integration Step-dependent Test Equipment. Knowing the integration concept and the
integration plan enables the design of the integration tools and test equipment. Since the
integration process is exposed to risks such as units being ready for integration in a different
order than the planned one, special care should be taken to ensure the flexibility of the tools
and test equipment.

Actions at the Sub-system and Unit Design Stage. At this point nothing is new. Repeating
the actions described Section 3.3 until the level of units is achieved is recommended.

Looking Forward Integration Summary. Figure 2 graphically shows the looking forward
methodology. It shows the relationship between the left and right sides of the "V" and the
action/s to be taken between the two stages.
Figure 2. Graphical Presentation of the Looking Forward Methodology

4. Actual Use Report


Upgrading an old aircraft is not an easy task since not all the data about the aircraft may be
available. The integration stage of this kind of project suffers from many uncertainties.
The methodology presented above was used for the first time in 1994 two-year project for
upgrading an old aircraft. During negotiations with the customer, requirements analyses were
performed. From the results of the analyses, it appeared that airborne test equipment was
essential for the project integration. Definition of the test equipment required an airborne
computer capable of listening to communication on the aircraft channels. The customer asked
for the reason for needing such expensive test equipment. After a short explanation was
provided, the customer agreed and demanded that the test equipment be turned over to him at
the end of the project. This was a win-win situation; the firm making the repairs had no need
for the test equipment after the project ended and the customer needed the equipment to make
better use of the system.
Had the need for the test equipment been discovered after the contract had been signed, the
firm doing the upgrade would have had to bear the cost of the equipment. Additionally, if the
team doing the upgrade had realized later on in the project that they needed the test
equipment, it would have been very expensive to develop it quickly and the tester
performance would have suffered as a result.
The test equipment was designed to be flexible. Extra analog and digital communication ports
were added to the tester. The project integration on the ground was relatively smooth until we
reached the flight tests. Using the tester, it was seen that on one communication channel there
was an unacceptable delay. It was obvious that without the tester, the problem would very
hard to detect. The system sampled analog data directly from the aircraft instead the
communication channel and the testers flexibility enabled monitoring this process. Finally,
the two-year project was finished on time despite many unexpected problems.
5. Conclusions
A structured methodology for building an integration process from the customer
requirements until the project validation tests were presented. The proposed methodology has
been used since 1994 in three large-scale projects and one medium-scale project. The large-
scale projects were upgrading old aircraft. The medium-scale project was a homeland
security project. The integration tools and the flexible testing equipment helped to modify the
tests according to changes in customer requirements and changes caused by improper design.
The test equipment helped detect and solve problems in the projects. The three large scale
projects were completed on schedule; the homeland security project was late.
The methodology was based on the well-known "V" model. For each step in the "V" model
there are forward-looking tasks:
1. At the requirement analyses stage Design the "Black Box" test and derive
requirements for testability and special test equipment.
2. At the system design stage Design the "White Box" tests and derive requirements
for testability and special test equipment. Design the interface and add testing
interface (test points and excitation points).
3. Repeat step 2 until you reach the part design.
Though the methodology was proven and helped produce good results, it is not free of
problems and difficulties. Some of the methodology difficulties we encountered:
1. The methodology requires flexible test equipment; it does not describe how to accomplish
this since this is not an easy task to design flexible test equipment. A lot of experience is
required to do it right and this task is a system-dependent task.
2. Choosing the right integration concept is not a structured methodology. The given
guidelines and points must be considered.
The proposed methodology, nevertheless, produces good results and is highly recommended.

References
Browning, T. R. 1996. Multi-Team Integration: Interdependence and integrative
mechanism. Paper presented at the Sixth Annual International Symposium of
INCOSE, Boston, MA (US), 711 July.
Buus, H., McLess, R., Orgun, M., Pasztor, E., and Schultz, L. 1997. 777 Flight controls
Validation Process. IEEE Transactions on Aerospace and Electronic Systems, 33
(2).
Power, G., and Wiersholm, O. 1996. Systems Engineering and Integration for DOE
Environmental Management. Paper presented at the Sixth Annual International
Symposium of INCOSE, Boston, MA (US), 711 July.
Sommerville, I. 2001. Software Engineering. Hoboken, New Jersey USA: Addison Wesley.
Tahan, M., and Ben-Asher, J. Z. 2008. Modeling and Optimization of Integration Processes
Using Dynamic Programming. Systems Engineering 11 (2):.
BIOGRAPHY
Dr. Meir Tahan was born in 1952 in Beer Sheva. Israel. Dr. Tahan received a Bachelor of
Science Degree (BSc) in Electronic Engineering from Ben-Gurion University in 1977, a
Master of Engineering Degree (ME) in System Engineering from the TechnionIsrael
Institute of Technology in 2001and a PhD in System Engineering from the TechnionIsrael
Institute of Technology in 2008. Since 1977 he has been involved with systems integration
and systems engineering, working in military and civilian projects. In 2010 Dr. Tahan joined
Ort Braude College as a lecturer in the graduate systems engineering program. He is a
member in the leading team of this program. In parallel, Dr. Tahan joined Plasan Ltd. as a
leading testing engineer.

Das könnte Ihnen auch gefallen