Beruflich Dokumente
Kultur Dokumente
Integration
Dr. Meir Tahan
Ort Braude College, Karmiel, Israel
tahanm@braude.ac.il
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.
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.
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.
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.
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
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.