ISSUE NO. 12 | July 2013

ISSUE NO. 12 | July 2013

The Voice of the Editor Amir Tomer

The Voice of INCOSE_IL President Moti Frank

Systems Engineering of Products Families Avigdor Zonnenshain

Optimizing System Architecture for AdaptabilityAvner Engel, Yoram Reich, Tyson R. Browning and Danilo M. Schmidt

Principles in Systems Array Engineering [abstract]Miri Sitton, Eran Reuveny and Moshe Weiler

Towards a Contingent Approach of Customer Involvement in Defense R&D Projects [abstract] Michael Peled

Lean-Agile Method for Shortening the Duration and Improving the Quality of Development [abstract] Uzi Orion

חזרה לתוכן עניינים חזרה לתוכן עניינים

Table of Contents

The Voice of the Systems

Table of Contents

The Hebrew part is on the opposite side

The Voice of the Editor Amir Tomer P. I-II

The Voice of INCOSE_IL President Moti Frank P. III-IV

Systems Engineering of Products Families Avigdor Zonnenshain P. V-VI

Optimizing System Architecture for AdaptabilityAvner Engel, Yoram Reich, Tyson R. Browning and Danilo M. Schmidt P. VII-XX

Principles in Systems Array Engineering [abstract]Miri Sitton, Eran Reuveny and Moshe Weiler P. XXI

Towards a Contingent Approach of Customer Involvement in Defense R&D Projects [abstract] Michael Peled

P. XXII

Lean-Agile Method for Shortening the Duration and Improving the Quality of Development [abstract] Uzi Orion

P. XXIII

ISSUE NO. 12 | JULY 2013

I


Table of Contents

Dear Readers, Another Israeli company has recently realized the dream of thousands of Israeli hi-tech entrepreneurs: Waze has been purchased by Google for a fortune of over one Billion dollars. The company’s attraction and the very high value the purchasers agreed to pay were not based upon a breaking-through innovation or an ingenious algorithm, but rather on a simple idea of unique incorporation between two existing and popular technological areas: A navigation system and a social network. The global “cloud”, in which we live today, calls for infinite “matching” opportunities between existing systems, which provides the ability to bring to our finger-tips capabilities and possibilities, which we may have not thought about by ourselves. Have the development processes turned upside-down? Is instead of the traditional approach of defining needs and requirements, followed by product design and implementation, we now experience a process which defines requirements and needs for the customers on the basis of existing products? Actually, we may notice that this trend is not new, and what enabled it is the evolvement of connectivity conventions, such as TCP/IP protocol, USB, Bluetooth, etc. A car communicating with a traffic light, an ECG device operated by a cellular phone and an innocent shopping list which predicts the pregnancy of its shopper – all of these do not surprise us anymore, and whatever does not exist today, will exist tomorrow. Is the Systems Engineering process is also changing, following this trend? Is “integration” replaced by “interoperability”? Is the Integrated Project Team is replaced by a standardization forum? Are requirement today stipulated by manufacturers and developers and not by the market and the customers? Food for thought.

The first article in this 12th edition of “The Voice of the Systems” addresses exactly this issue: Miri Sitton, Eran Reuveny and Dr. Moshe Weiler – all of them have vast experience in Systems Engineering – conduct, at the Gordon Institute, a research which deals with the engineering challenges in the development of Unsynchronized Systems Arrays. The article, which summarizes their research report, discusses the engineering challenges, the typical risks and the fundamental principles in unsynchronized development.

The article by Dr. Avner Engel, Prof. Yoram Reich and their colleagues from abroad also addresses the issue of the adaptability of systems to new environment and unpredicted future requirements. The authors presented an analytic model, which they developed, for identifying architecture alternatives in the range between a cheap and inadaptable system and a costly system with high degree of adaptability. This model enables to identify a system architecture which optimally balances between cost and adaptability. The article was presented and published in the DESIGN 2012 conferences and is re-published here under the courtesy of the copyright owners – The Design Society.

Dr. Michel Peled, from IAI, explored in his Ph.D. thesis, under the guidance of Prof. Dov Dvir, the various aspects of customer involvement in projects in the Israeli defense industry, and the effects of this involvement on project success. The research was based both on quantitative data and analysis (from 155 projects) and qualitative case investigation (in 13 projects), and examined the relations between the characteristics and modes of customer involvement and the characteristics of the projects. A principle process for establishing a customer representative in a given project is introduced based upon the research findings. The article awarded “best paper” in the INCOSE_IL 2013 conference. Uzi Orion from Elbit Systems (ElOp) – one of the most appreciated Systems Engineering champions in Israel, is constantly working on applying new methodologies to system development. In his article Uzi reports about a successful combination of two new approaches: Agile Systems Engineering and Lean Systems Engineering, which resulted in development of several complex projects while avoiding unnecessary waste, shortening the schedule and meeting the budget, while providing a high level design maturity.

I

חזרה לתוכן עניינים

The Voice of the Editor


II


Table of ContentsII


Dr. Avigdor Zonnenshain summarizes the Yossi Levin Systems Engineering seminar on product families, which was conducted in the Gordon Institute on January 2013. In addition, Avigdor enriches us, as usual, with information on Systems Engineering news in Israel and in the world. This edition is published on the day of the Dr. Zeev Bonen Systems Engineering seminar at the Gordon Institute, which is dedicated to System of Systems Engineering.

This edition of “The Voice of the Systems” is the first under the presidency of Prof. Moti Frank – the new INCOSE_IL president. In his opening words Moti reviews the challenges and the goals faced by him, by the association and by all of us in the intensive activity of INCOSE_IL. We wish Moti and all of us a lot of success in meeting all the goals.

I wish you pleasant reading.

Dr. Amir Tomer, CSEPKinneret Academic CollegeThe [email protected]


III


Table of Contents

Hello to the Israeli Systems Engineering Community,Systems Engineering has evolved at the US Ministry of Defense and in NASA since the 1960’s but only in 1990 the INternational Council on Systems Engineering (INCOSE) was established (initially as the American National Society of Systems Engineering). In Israel too, Systems Engineering evolved in the large defense industry and in the technological bodies of the government defense organizations.

For those dealing with Systems Engineering it was intuitively clear that this is the right way to work in system projects, but quantitative data to support this intuition were missing. Recently, findings of a research1 , which examined 94 system projects over 15 years, were published. The research found significant correlation between the investment in Systems Engineering, as ratio of the total project cost, and the project’s success, in terms of cost, schedule and overall success, as perceived by its stakeholders.

Many other findings are presented in the research report – a remarkable one is the significant correlation between the Systems Engineering’s human factor (Technical Leadership/Management) and project success: The level of the systems engineer, both from the engineering and the technical management aspects, has major importance for the success of the project.

This finding adds to similar findings, found in many other researches, and is pointing once again to the importance of Systems Engineering to project success. It seems that the past dilemma, whether to invest in establishing Systems Engineering in project-intensive organization, does not exist anymore. The large Israeli defense industries and the technological bodies in the Israeli government defense organizations system have long realized this, but in most of the small and medium “civilian” companies there is a debate about establishing Systems Engineering processes. Companies who have already decided to establish Systems Engineering processes are still debating how to implement it.

We, at the Israeli Association of Systems Engineering (INCOSE_IL), are convinced that Systems Engineering in Israel should be treated as a strategic asset and an area with relatively large advantage. Therefore we decided that side-by-side with strengthening Systems Engineering in the defense organizations, and along with strengthening the links between Industry and Academia, we will also act to endow the large knowledge acquired in this area to smaller companies. Accordingly, a large part of our activity in recent years is oriented towards small and medium civilian companies.

Increasing the number of companies applying Systems Engineering processes is just one of the goals I have set upon entering my position as INCOSE_IL president. Other goals, which were approved by the association’s directorate, are: Expanding and deepening the knowledge, knowledge sharing, adaptation of methods to the Israeli needs, developing new methods and deepening research in the Industry and Academia; Expanding the application of methods and the circle of users among Israeli companies; Knowledge distribution, among both defense industries and civilian industries, who do not apply these methods yet; Cooperation between the association and Industry-Academia-Government, as well as cooperation with other professional organizations; Distribution of System Thinking strategies among decision makers at all levels; Entering into newly evolving areas in Israel and in the world; Involvement in and cooperation with INCOSE, and making Israel being recognized as a knowledge center in Systems Engineering.

1. An extract from Eric Honour's Ph.D. research was published in the 10th Edition of The Voice of the Systems (June 2012). The full report can be found in http://www.hcode.com/seroi/index.html

The Voice of INCOSE_IL President


IV


Table of ContentsIV


Prof. Moti FrankINCOSE_IL [email protected]

Our main goals are, therefore, creation, distribution and sharing of Systems Engineering knowledge for all those applying Systems Engineering in Israel. To achieve this we conduct various activities, such as biennial national conference, technical meetings, symposiums, seminars, lectures and work-groups. The last national conference, conducted in March 2013, was a great success which attracted over 500 people dealing with Systems Engineering, such as Systems Engineers, academic personnel, military officers and others interested.

In this occasion I would like to thank to all the active people who volunteer to promote Systems Engineering in Israel. A special tribute I would like to pay to the members of INCOSE_IL directorate for their dedication to promoting the association and its goals, and to Moshe Salem, who administrate the association’s activities from its first day.

Sincerely,


V


Table of Contents

Systems Engineering of Products Families – The Best Integration of Engineering Aspects

with Marketing and Economical AspectsSummary of the Systems Engineering Seminar – 9.1.2013

Organized by the Gordon Center for Systems Engineering in commemoration of Dr. Yossi Levine

Recognition for Excellence in SEThe annual Systems Engineering Day, in commemoration of Dr. Yossi Levine, was conducted On January 9th, 2013. Two Systems Engineers – one from RAFAEL and one from IAI, awarded as “Excellent Systems Engineers” at the opening ceremony.

Systems Engineering of Products Families

The seminar focused on systems engineering of products families, by presenting approaches, processes and tools for optimal design of products families.

The keynote speaker was Prof. Olivier de Weck from the MIT. Prof. de Weck, who is one of the leaders in the MIT program of Engineering Systems, introduced a well defined methodology for designing product families based on integrated aspects of technology engineering, economics and marketing. He presented the 10-10-10 rule for implementing the methodology which recommends to design and plan a product family if the initial investment is at list $10M, the uncertainty in the market is at least 10% (sigma), and the expected system life spans over more than 10 years.

Managing Software Products LinesYaron, from a software group in RAFAEL, described their method for managing software product lines. The motivation for developing and managing software product lines is arises from customers who have similar, but not identical, requirements, short time-to-market which drives for using existing building blocks, and the ability of such building blocks to go through standardization and rigorous quality processes. In addition, using the same building blocks in several products may improve the detection of bugs. At this stage, the software group is preparing the methodology for developing product lines and has initiated pilots in several projects.

Evolvement of Radar FamiliesAvi Leshem from ELTA/IAI described the evolvement of the Radars families from the seventies till these days, which have evolved through both capabilities and technologies. These families have been developed from the beginning with product-families approach, which means that certain units and certain technologies developed to become communal units and communal technologies for various types of Radar. As technology evolved, new capabilities were developed and were incorporated in future product families.

Dr. Avigdor ZonnenshainRAFAEL


VI


Table of Contents

Requirement Challenges in Products FamiliesMimi Timnat, Systems and Processes Engineer in Elbit Systems, presented the aspect of requirements management in products lines. Mimi emphasized the need to define requirements for developing core capabilities, which will serve various product families.

ReuseA common practice in product families is, of course, the reuse of modules, printed cards and software packages. Dr. Amir Tomer from Kinneret College presented an economic model for selecting among several alternatives of reuse. According to this model Systemic Reuse provides the best cost-effectiveness in the long run.

Resilient Systems for Human ErrorsAvi Harel from Ergolight and Dr. Avigdor Zonnenshain from RAFAEL presented resilient systems for human errors, which were demonstrated on alarm and alert systems. In these types of systems it is recommended to add a special interface which assures resilience. In addition, it is recommended to add an element which will enable analysis and recovery in real time.

Optimal Architecture based on a platformHenry Brodney, from IBM Research Labs in Haifa, presented methods and possible tools that contributes to the optimization of the architecture based upon a common platform. This methodology has been demonstrated in selecting the architecture of an airplane.

Simulation as an aided tool for decision processesMichal Iluz from RAFAEL described a joint research with prof. Avi Shtub from the Technion. The work focuses on using simulations for planning projects according to agreed assumptions. It was demonstrated that using the simulators improve the way of decisions making.

Conclusions and what nextThis day brought up to the center of the stage the importance of systems design of products families from engineering, economic and business aspects. It is our intension to elaborate on this subject in upcoming meetings and researches..

The presentations of this day & the photos are available on the Gordon Center site:

http://www.gordon-se.technion.ac.il/news-events/levin-day-9113


VII


Table of Contents

Originally published in:

INTERNATIONAL DESIGN CONFERENCE - DESIGN 2012

Dubrovnik - Croatia, May 21 - 24, 2012.

Re-published with permission from The Design Society.

OPTIMIZING SYSTEM ARCHITECTURE FOR ADAPTABILITYA. Engel, Y. Reich, T.R. Browning, D.M. Schmidt

Keywords: Systems Architecting, Modularity, Transaction Costs, Financial Options, Architecture Options, DSM, Optimization, Adaptability, TRIZ

AbstractSystem architecture decisions such as the assignment of components to modules can

have a large impact on the system’s adaptability. We broaden systems architecting theory by considering components’ option values and interface costs when making the assignment decision. We build and test an analytical model to identify the tradeoffs between an inexpensive but inadaptable system and an expensive but adaptable one. We demonstrate the model with a realistic example of an Unmanned Air Vehicle (UAV) and use a genetic algorithm to identify an architecture that optimally balances cost and adaptability.

1. IntroductionA system’s overall lifetime value can be improved if its useful service life can be increased.

However, since a system’s stakeholders change their desires over time, the system’s value (in terms of its fit with those desires) will diminish unless it can be adapted (Fricke and Schulz, 2005). Thus, adaptability, the ability of a system to be changed to fit varied circumstances, is often a valuable attribute of system performance. However, since adaptability may come at a cost, more is not always better: investments in adaptability may provide diminishing or even negative returns. Therefore, it is essential to allocate resources for adaptability at an appropriate level and to the most effective locations in a system architecture.

Extending the work of Engel and Browning (2008), this paper presents an updated model of a system architecture that accounts for component option values and interface costs. The model includes an updated objective function that incentivizes segregating components with high option values and aggregating components with high interface costs. Next, moving beyond previous work, we apply the model to a hypothetical but highly realistic unmanned air vehicle (UAV) to demonstrate the variance in overall system value as a function of different component aggregations (i.e., assignments to modules). Finally, we apply an optimization model to seek the optimum architecture from an adaptability perspective. These results provide interesting insights for system architects and managers, regarding engineered systems as well as customer service.

2. Architecting Systems for Optimal AdaptabilitySered and Reich (2006) showed how standardization and modularization of a systems design

can minimize its overall development effort. Standardization involves expending extra efforts upfront to design robust parts that would work in any foreseen situation. Consequently, it is assumed that expected external changes would not lead to any change in the standardized


VIII


Table of Contents

components. Modularization means that interfaces among components are established in advance, so that changes would be likely to be isolated within specific modules and not propagate to interfacing modules. Consequently, future changes would be likely to cost less, because they would be likely to affect fewer modules. In this way, component modularization choices and investments in interface standardization (a design cost) purchase an option for reduced redesign costs. However, the correct combination of standardization and modularization implies a tradeoff. Browning and Honour (2008) proposed a method to measure the overall lifecycle value of an enduring system. Such a measure provides a more comprehensive basis for directing system architecting investments than merely using overall development effort, which does not account for future redesign costs and will therefore always undervalue investments in adaptability. Based on these concepts, Engel and Browning (2008) reviewed ideas from options theory, transaction cost theory, and system architecting and developed an optimization model for a system architecture’s adaptability value (V). Adaptability value is an index used to represent the relative costs and benefits of changing a system after its initial deployment. Essentially, options theory provides a theoretical basis for addressing the future value of the system, and transaction cost theory provides a basis for dealing with interfaces between its components. These concepts were combined to produce the following model1:

(1)

where M is the number of modules, and Xm is the adaptability value of the mth module, defined as:

(2)

where OVm is the aggregated option values of the components, and ICm is the aggregated (external) interface costs, of the mth module.

A basic tenant of option theory is that many small options are more desirable than a few large ones (because they provide more future flexibility in exercising the options). Hence, the adaptability value of a system should increase with the number of modules (where, in the extreme, system components are synonyms with modules).2We model this as:

(3)

where N is the number of components in the overall system and Nm is the number of components in the mth module, such that . The aggregated interface cost of each module accounts for its external interfaces:

(4)

where I are the interface costs between component m and other components outside its module (interface costs within the module are ignored for purposes of this calculation), and the N+1th component represents interfaces with any components outside the system. (The i, j, and k indices refer to the interface’s position in a design structure matrix [DSM] layout.) The overall model to be optimized is therefore:

(5)

A component’s OV is estimated via an application of the Black-Scholes financial option pricing method (Black and Scholes, 1973), as described in Engel and Browning (2008). Each interface cost is computed by including the costs of developing, producing, maintaining, and disposing the interface3.

1. While keeping in mind the updates noted, see Engel and Browning (2008) for further explanations of the model’s components.2. Engel and Browning (2008) introduced a parameter called the Adaptability Factor to account for the difficulty of upgrading a

system in the future. Upon further evaluation, we realized that this element could be considered as already built into the Black and Scholes equations. Hence, it does not appear in equation (3).

3. The reader should note that all the right-side variables of equation 5 express monetary values (i.e., Dollars, Euros, Drachmas, etc.). Therefore, the architecture adaptability value (V) itself expresses a monetary value.

1

Mmm

N N=

=∑

1Max V M

m mX

==∑

m m mX OV IC= −

21( )mN

m iiOV OV

== ∑

( )1 1

1 1 1mN N N

m ij kii j kIC I I+ +

= = == +∑ ∑ ∑

( )1 121 1 1 1 1

Max ( )m mM N N N Ni ij kim i i j k

V OV I I+ +

= = = = = = − + ∑ ∑ ∑ ∑ ∑


IX


Table of Contents

The assignment of components to modules determines whether a particular interface is rendered internal or external to a module. We apply principles of transaction cost theory (Coase, 1937), and the high likelihood that all of the components in a module will be redesigned collectively, to assume that interfaces within a module have negligible interface costs for the purposes of this model.

Thus, the model rewards (value increases) the isolation of components from one another (due to their increased option potential) but penalizes (value decreases) when such a segregation exposes high interface costs. Equation (5) creates a tradeoff between the benefits of having many small options and the costs of the interfaces to maintain them. Thus, the optimal assignment of components to modules will maintain sufficient option value (future adaptability) at a reasonable interface cost. The maximum value architecture is unlikely to contain either extreme solution: an architecture with M ≈ N or an architecture with M = 1. Note that the model’s weightings of the two competing terms is based on past literature but remains open to adjustments based on empirical validation and the characteristics of particular instances.

3. Model solutionWe attempt to optimize the model with a genetic algorithm that explores varied assignments of components to modules, taking into account the constraints among components and with the system’s environment (all of which are captured in a design structure matrix [DSM] representation). The basic operation of the genetic algorithm is classical. One point worth mentioning is the representation of architectures. Suppose we have N components. Consequently, there could be as many as N modules in the architecture. Each member in the initial population is a possible architecture. Its N components are randomly assigned to the N potential modules.

Figure 1 illustrates the approach: In (1), each of the N = 8 components has been assigned to a different module. In (2), the eight components have ended being in two modules, whose name are arbitrarily referred to as “4” and “3”. In (3) one descendent after a crossover between (1) and (2) is depicted, where the crossover is after position three. In (4) the second descendant is depicted. Architecture (3) has four modules and architecture (4) has six modules. In our investigations so far, we have found that sufficient population size4 and enough iterations5 allows this simple representation to converge to what seems to be an optimum.

Figure 1: Architecture Representation and Crossover Operator

4. ExampleWe apply the model to an example of an Unmanned Air Vehicle (UAV) system.

4. As a rule of thumb, population size should be equal or exceed the number of components.5. This information may be determined experimentally, considering the stability of optimization results and the available

computations resources (especially time).


X


Table of Contents

4.1 The UAV SystemA UAV (see artist rendering view depicted in Figure 2) is utilized for information gathering

where extended mission times are required. Day (video) and night (Infra-Red) images are obtained in order to monitor forest fires, flooding and other disaster situations or for military purposes. The information is transmitted from the Air System (AS) to the ground station via radio signals. Operators in the Ground Control Station (GSE) send commands and receive status and payload images from the AS by means of the Ground Communication (GCO) subsystem. One or more Remote Terminal (RT) subsystems, located within the transmission range of the AS can also receive images from the AS and display them to remote observers. The AS itself may be launched automatically from the Launcher (LNCR) and land autonomously on a designated landing strip. The Support Equipment (SE) subsystem provides facilities to test and analyze the status of all system elements. Finally, the Simulator (SIM) provides means for training the GCS operators in all aspects of handling the UAV system under simulated mode.

Figure 2 - UAV System (Artist Rendering View)

4.2 UAV System ArchitectureFigure 3 depicts the “as designed” UAV system architecture as a block diagram, and Table

1 describes the UAV’s system hierarchy including “leaf” components. These leaf components are defined as the lowest level elements which are of interest to a particular system designer.

The “Exclusions” column indicates mutually exclusive component sets. There are three mutually exclusive sets in the table: the AS subsystem, the RT subsystem (both identified in Figure 3), and the rest of the UAV system. Components from mutually exclusive sets cannot reside within a single module due to spatial, technical or managerial limitations and therefore may interact only by means of an interface.


XI


Table of Contents

4.3 UAV Interfaces and Their CostsThe internal and external UAV system interfaces are depicted in Table 2. An example of a

component-level interface cost is depicted in Table 3. The cost of each interface is derived from summing up the costs of materials, labor, and other expenses incurred during the lifetime of the interface (i.e., development, production, use/maintenance, and disposal phases). These estimates can be based on historical data or made by systems engineers.

Figure 3 - UAV System in its Environment - Block Diagram

Table 1 - “As Designed” UAV System Architecture

Air System (AS)

UAV System

Ground Control Station (GCS)

Air Vehicle(AV)

Support Equipment (SE) Launcher (LNCR)

Payload(PYLD)

Ground Comm. (GCO)

Ground System

Air Mission(AM)

Air Comm.(AC)

Ground Control (GC)

Remote Terminal (RT)G

CO

. Tra

nsm

itter

(GC

O-T

RN

S)

GC

O. R

ecei

ver

(GC

O-R

EC) RT Receiver

(RT-REC)

RT Control(RT-CON)

Pilot Bay (PBY)

Observer Bay (OBY)

Planner Bay (PLBY)

Analyzer Bay (ABY)

GCO. Control(GCO-CON)

RT Display(RT-DIS)

Ground Control Test(GCS-TST)

Air System Test(AS-TST)

Ground Comm. Test(GCO-TST)

Remote Term. Test(RT-TST)

AV-Bus

GC

S-Bu

s RT-

Bus

SE-B

us RT-

Test

GC

O-T

estGC

O-T

est

RT-

Test

AS-Test

GCS-Test

SIM-Com

LNCR-Com

TRNS-Com REC-Com

Simulator (SIM)

GC

O-C

om

SIM Display (SIM-DIS)SIM Control (SIM-CON)

SIM

-Dis

p

Ground Positioning System (GPS)

Air Traffic Control (ATC)

Tactical Communication

(TAC-COMM)

TAC

-CO

M-D

TAC

-CO

M-D

GPS

-Dat

a

ATC

-Dat

a

DN-LNK-SDN-LNK-PUP-LNK


XII


Table of Contents

Table 2 - Internal and External UAV System Interfaces


XIII


Table of Contents

Table 3 – Example - Computing Interface Cost

4.4 Computing a Component’s Expected Future Gain in ValueIn order to use the Black-Scholes equation within an engineering domain, we must compute

the expected future value gain of each component. Table 4 exemplifies our extension to the TRIZ theory of evolutionary forecasting of technical systems (Mann, 2003). First, we examine each TRIZ “Law of Technical Systems Evolution” to identify relevant technical and/or business parameters likely to evolve and affect the value of the component during the studied timeframe (left hand-side of the table). Second, we evaluate the technical and business parameters in terms of their current and future level of improvements using an S-Curve methodology. Third, we estimate the relative weight of each parameter, ensuring a sum weight equal to 1.0. Next, we compute the initial and final weighted factors for each parameter and their corresponding totals. Finally, based on the component’s current value (S), we compute its expected future value (S’) and its expected value gain (S’-S). For instance, assuming the current value of a given component is 4,000€, we use the table to compute its future expected value (S’) and gain (S’-S) as:

1,2,...' '

1,2,...

* 4.75Future value = 4,000 7,900€ ; Gain = 7,900 4,000 3,900€* 2.40

i ii

i ii

F WS S S S

I W=

=

= = ≈ − = − =∑∑


XIV


Table of Contents

4.5 Architecture Adaptability ValuesWe use a DSM to record the OV and interface data used by the model. The OV of each

component is positioned along the diagonal of the DSM, and the Interface Costs are placed in the appropriate cells off of the diagonal. Figure 4 depicts the “as is” UAV system DSM with arbitrary but realistic OVs and interface costs. In this architecture, each component is its own module. This architecture provides maximum adaptability but requires a significant investment in interfaces (during design, testing, manufacturing, maintenance and disposal). This architecture has an adaptability value of V(1) = -6,560€, meaning that the interfaces are quite expensive and dominate the result. Figure 5 depicts the new component assignments to modules after 10,000 iterations of the GA, with an architecture adaptability value of V(2) = -1,797€, a 73% improvement.

Table 4 - Example - Computing the Expected Future Value of a Component


XV


Table of Contents

Figure 4 - “As Is” UAV System DSM

Figure 5 - Optimized UAV System DSM


XVI


Table of Contents

The intuitive approach to architect adaptable systems might be to base the design on a large number of small modules (represented, e.g., in Figure 4). Indeed, if adaptability was unrelated to cost, this would have been the correct solution. However, such architecture requires dealing with more interfaces, and the cost of these interfaces must be balanced and exceeded by the benefits of adaptability, all expressed in monetary terms. Consequently, it should not be a surprise that the optimized result leads the designer to create a more adaptable architecture, yet one that balances transaction costs, segregating components with high option values and aggregating components with high interface costs.

A far better optimization result could have been achieved had the optimizer not being constrained by the exclusion rules (defined in Table 1). Such an architecture would have an adaptability value of 934€, but it generates a single module combining the Air communication component (residing in the air vehicle) with the ground communication subsystem. As predicted, the optimized architecture tends to lump groups of components into identified modules to optimize the tradeoff between higher adaptability and lower cost. In addition, the optimizer “suggests” combining the air vehicle Launcher (LNCR) and the Ground Control Station (GCS) into a single module.

4.6 Comparison with a Conventional DSM Clustering SchemeOften, in a conventional DSM clustering scheme, the diagonal contains no data (this

corresponds in our model to having all Option Values equal zero). In addition, a one is placed when an interface exists between two components (this corresponds in our model to having all Interface Costs equal to one). With this set-up, Figure 6 depicts the conventional “as is” UAV system DSM and Figure 7 depicts a conventional optimized UAV system DSM.

Figure 6 - “As Is” Conventional UAV System DSMNotwistanding the exclusions, which prevent us from clustering the physically separated

system elements, one should observe the different results emanating from the two optimization schemes. In the conventionally optimized DSM (Figure 7), a set of ten components have been clustered into a single module (identified in color). However, optimizing system architecture


XVII


Table of Contents

for Adaptability leads to a more adaptable clustering solution made of three individual clusters (Figure 5). The algorithm incentivizes us to increase our up-front investment in establishing internal interfaces, therefore segregating components with high option values when interface costs are economically viable. At the same time, interacting components with high interface costs would tend to be clustered into a minimum number of modules (see for example components GCO-TRNS, GCO-REC and GCO-COM in Figure 5).

Figure 7 - Optimized Conventional UAV System DSM

5. The Model as an Engineering ToolComputational tools for doing a particular task offer immediate benefits to their users. In our

case, the availability of a tool for calculating adaptability values is used to perform sensitivity analysis to provide a deeper understanding of the architecture design space. For example, consider the data in Figure 4 and assume that the future value of the system cannot be discerned with reasonable accuracy. The system engineer could analyze the resulting architecture with a set of factors multiplying the estimated OV and IC values. Suppose also that the designer has some control over different types of interfaces that would lead to different costs. Such variation would lead to a space with varying OV and IC factors (see Figure 8(a)). By performing simulations in this space, a map depicting the number of modules as a variation of the OV and IC values could be constructed. One should remember that the same number of modules does not mean the same modules; e.g., there are many possible ways to create five modules from 21 components. Nevertheless, such modules could be represented by a lattice in a way that distinguishes them and allows for more detailed analysis. Such analysis is left for a future paper.

Suppose that the present values position the situation at point (1) in Figure 8(b). The availability of the simulations shows the system engineer that the decision regarding the number of modules that provide the best future adaptability value is sensitive to the estimations of OVs and ICs. Given the importance of the decision, the chart focuses the engineer to better estimate these values. When done carefully, the analysis would focus the engineer on particular component OV and ICs to study further.


XVIII


Table of Contents

As another example, consider a situation in which the future system value is hard to estimate, line (2) in Figure 8(b). In this case, the simulation could be executed with varying inputs, and the engineer could observe the consequent transition between different architectures and make a choice even without knowing the exact future value. This analysis capability provides a way for engineers to determine whether their estimates are robust (do not have significant impact on the results) or require further work (have impact on the results).

(a) The adaptability sensitivity space (b) Focusing on critical decisions

Figure 8 - Adaptability Sensitivity Space

We executed such an analysis for our case study by varying OV and IC and the results are shown in Figure 9. The solution shown previously in Figure 5 chose six modules. However, it is clear from the sensitivity study in Figure 9 that, near the present inputs—i.e., (IC, OV) = (1, 1)—a slight increase of the OV values would lead to seven modules as the best choice. Consequently, better estimates of the OV factors might be worthwhile to obtain even at some extra cost.

Figure 9 - Case Study Adaptability Sensitivity Space


XIX


Table of Contents

6. ConclusionsWe presented a modified adaptability model that uses options and transaction cost theories

to find a tradeoff between a monolithic, non-adaptive, but less expensive (to develop initially) system and a fully adaptive but expensive one. The tradeoff is found by combining some components into modules and thus saving their intra-module interface costs. The particular modules depend on the mix of the components’ future option values and their interface costs. We demonstrated the application of this model to finding a cost-effective, adaptable architecture for a UAV system. Furthermore, we briefly discussed how this model can provide insight to systems engineers in making more sensible design decisions by performing sensitivity analyses with the model. Executing the model on real cases will be performed in the future as part of a large research project that will test the proposed model thoroughly.

7. AcknowledgmentPartial funding for this research work was received from the European Commission; project

AMISA (Call identifier: FP7-NMP-2010-SMALL-4, Grant agreement: 262907). More information about the AMISA project is available at Website: http://www.amisa.eu/.

Additional support for the first two authors was obtained by the Israel Science Foundation under Grant 765/08.

The third author is grateful for support from the U.S. Navy, Office of Naval Research (grant no. N00014-11-1-0739).

8. ReferencesBlack F. and Scholes M., The pricing of options and corporate liabilities, Journal of Political

Economy, 81(3): 1973.

Browning, T.R. and Honour, E.C, Measuring the life-cycle value of enduring systems, Systems Engineering, 11(3): 187-202, 2008.

Coase R., The nature of the firm, Economica 4 (16), pp. 386-405, November 1937.

Engel, A. and Browning, T.R., Designing systems for adaptability by means of architecture options, Systems Engineering, 11(2):125-146, 2008.

Fricke, E. and Schulz, A.P., Design for Changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle, Systems Engineering, 8(4): 342-359, 2005.

Mann, L.D., Better technology forecasting using systematic innovation methods, Technological Forecasting and Social Change, 70(8):779-795, 2003.

Sered, Y. and Reich, Y., Standardization and modularization driven by minimizing overall process effort, Computer-Aided Design, 38(5):405-416, 2006.


XX


Table of Contents

Dr. Avner Engel, holds a B.Sc. in Electrical Engineering from the University of Maryland, an M.Sc. in Computer Systems from the University of New York and a Ph.D. from the Industrial Engineering department of the Tel-Aviv University. His 40 year professional career spans the areas of programming, systems and software engineering, and technical management with several large companies in the US and Israel. For the past twenty years, he has worked for the Israel Aerospace Industries (IAI), where he has managed large software

and systems projects. He wrote a comprehensive reference book “Verification Validation and Testing of Engineered Systems” published in 2010 as part of the Wiley-Blackwell series in Systems Engineering and Management. He is currently a systems researcher and the AMISA (Architecting Manufacturing Industries and systems for Adaptability) project coordinator at the Tel Aviv University and also teaches systems engineering courses at the Faculty of Technology Management, Holon Institute of Technology (HIT), Israel.

Prof. Yoram Reich, is a full professor at the Faculty of Engineering, Tel Aviv University; received his BSc (Summa Cum Laude) and MSc (Magna Cum Laude) in Mechanical Engineering, Tel Aviv University. Before obtaining the PhD degree in Civil Engineering from Carnegie Mellon University, he practiced design for over 7 years in the audio, structures, and marine industries. Prof. Reich has authored about 200 papers. He is Editor-in-Chief of the journal Research in Engineering Design and a member of the editorial board of the journals International Journal

of Mass Customization, Journal of Engineering Design, International Journal on Sciences of Industrial and Systems Engineering and Management, Advances in Enterprise Systems, International Journal of Design Creativity and Innovation, and SDPS Transactions: Journal of Integrated Design & Process Science (JIDPS). His research focuses on product design methods and theories, flexible development processes, computer-aided design, data mining, and design research methodology. He is a member and an Advisory Board member of the Design Society, a member of INCOSE, and previously was the chair of the Israeli chapter of the Society of Manufacturing Engineers. Recently Prof. Cofounded the Israeli Institute for Empowering Ingenuity and is serving as his president.

Prof. Tyson Browning, is Associate Professor of Operations Management in the Neeley School of Business at Texas Christian University (USA), where he teaches MBA courses in operations management, project and program management, and Six Sigma. Dr. Browning holds a B.S. in Engineering Physics from Abilene Christian University and two Master of Science degrees and a Ph.D. from MIT. He has industrial experience at Lockheed Martin, Boeing, Honeywell, Los Alamos National Laboratory, and the Lean Aerospace Initiative and has

conducted research at and provided consultation for a number of other organizations. He has published over 40 peer-reviewed papers in the areas of systems engineering, engineering management, risk management, and process improvement. His current research addresses the modeling of adaptive processes and other aspects of managing large, complex engineering projects. He is a member of the International Council on Systems Engineering (INCOSE), the Institute for Operations Research and the Management Sciences (INFORMS), and the Production and Operations Management Society (POMS).

Danilo Schmidt, is Ph.D. student at the Institute of Product Development, Technical University of Munich.


XXI


Table of Contents

Systems Arrays Engineering Principles

AbstractThis report reviews the challenges and the complexity involved with Very Large-Scale Integrated Development Programs (VLSIDP). The report suggests to distinct between two type of VLSIDP: (1) Large Scale integration effort with clear engineering, program management and business relations (2) Large Scale integration effort which takes place along time, between different parties with no common vision or common goals, based on local interests. It is proposed to call this type of engineering effort Unsynchronized Systems Arrays engineering effort, as opposed to Systems of Systems engineering effort.The report has four sections. The first Section depicts the characteristics of Unsynchronized Systems Arrays programs. The second Section describes Unsynchronized Systems Arrays program risks. The third Section discusses 10 principles program management program engineering should master when running Unsynchronized Systems Arrays programs. The fourth Section summaries and compares the characteristic of Systems of Systems engineering to the characteristic of Systems arrays engineeringThe report concludes that it is essential for program management and program engineering to identify the type of large scale integration program they need to conduct. The report fully agrees with Watts Humphrey’s conclusion, that unless steps like those outlined in this report are taken in conjunction with continuing technical research and development, the large-scale systems development efforts of the future will almost certainly fail.

The full article in Hebrew is on page XIII of the Hebrew section.

Miri Sitton, Eran Reuveny and Moshe [email protected], [email protected], [email protected]


XXII


Table of Contents

Towards a Contingent Approach of Customer Involvement in Defense R&D Projects

AbstractThe article summarizes a study carried out recently in the faculty of management of Ben-Gurion University in the Negev, under the guidance of Prof. Dov Dvir. The study examined customer involvement practices in Israeli defense industry R&D projects, focusing specifically on the range of customer representatives’ roles of supervision and participation in project activities. The study proposes a theoretical contingency model and hypotheses regarding the effects of customer involvement modes on project success, moderated by project characteristics. A mixed-methods research was conducted, combining findings from a qualitative multiple case study of 13 projects and a quantitative survey of 155 projects. Practical managerial guidelines may be derived to adapt customer involvement practices to project characteristics, improving the involvement cost-effectiveness and contribution to project success.

The full article in Hebrew is on page XIX of the Hebrew section.

Michael PeledIAI and Ben-Gurion University

[email protected]

Winner of the "Best Paper" award,

INCOSE_IL 2013 Conference


XXIII


Table of Contents

Winner of the "Best Paper" award,

INCOSE_IL 2013 Conference

Lean-Agile Method for Shortening the Duration and Improving the Quality

of Development

AbstractThe paper deals with a new method for developing complex projects, based upon combining Lean Systems Engineering with Agile Systems Engineering. Studies have found that the success rate of project development, i.e. meeting schedule, budget and performance, is inversely proportional to project size. This leads to the thought that large projects can be broken down into smaller work-packages which will be allocated to smaller development teams. This approach also enables to overcome the “knowledge paradox” which claims that we need to make the most significant decisions at the beginning of the project, when our knowledge is the least. Adding to this the avoidance of waste, which contributes no value to the customer according to the Agile SE process, and advanced approaches to team management, we get a dynamic approach for developing complex projects. In all the projects where we applied the method, or parts of it, we managed to meet the schedule (in some cases even ahead of time), which also resulted in meeting the budget. The performance and design maturity were much better than the average in projects that were concurrently developed in the same companies.

The full article in Hebrew is on page XXXIV of the Hebrew section.

Uzi OrionDirector for Technological Initiative and Development

Elbit Electro-optic Systems [email protected]

ISSUE NO. 12 | July 2013

graphic design studio MediaHut

Documents

ISSUE NO. 12 | July 2013