ISSUE NO. 13 JANUARY 2014 - iltam.org · We started to prepare a series of 10 meetings on Systems Engineering ... industry of systems of systems in various sizes. Prof. Jamshidi

ISSUE NO. 13 | JANUARY 2014

The Voice of the Editor Amir Tomer

The Voice of INCOSE_IL President Moti Frank

Systems of Systems Engineering – Do We Need a Paradigm Shift? Avigdor Zonnenshain

Model Integration – Extracting Value from MBSEHenry Broodney, Uri Shani and Aviad Sela

Systems Integration – Do It Right First TimeMeir Tahan

On Risk and Safety [abstract] Michael Maharik

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

Table of ContentsTable of Contents

The Voice of the Editor Amir Tomer P. I

The Voice of INCOSE_IL President Moti Frank P. III

Systems of Systems Engineering – Do We Need a Paradigm Shift? Avigdor Zonnenshain P. V

Model Integration – Extracting Value from MBSEHenry Broodney, Uri Shani and Aviad Sela P. VII

Systems Integration – Do It Right First TimeMeir Tahan P. XXIII

On Risk and Safety [abstract]Michael Maharik P. XXXIII

Table of Contents

The Hebrew part is on the opposite side

The Voice of the Systems


I



Dear Readers, The world of system development is progressing restlessly – the developed systems are becoming more and complex and sophisticated and systems which were developed independently, without prior integration, are required to cooperate in new integrated missions. In the last issue we brought an article that dealt with unsynchronized systems arrays and last July a conference day on Systems of Systems was conducted at Gordon Center, Technion. According to this trend ILTAM, the user group under which INCOSE_IL is operating, decided to put the Systems of Systems and the Complex Systems issues in the focus of the multi-year plan 2014-2019. For more details please refer to The Voice of INCOSE_IL President and to The Voice of ILTAM Manager (in Hebrew) in the following. You may also find a summary of the conference day mentioned above.

As the use of Model-Based Systems Engineering is spreading out and the number of supporting tools in increasing, the need for frameworks, which will enable cooperation and sharing among paradigms and tools, is increasing too. The IBM research center in Haifa deals with this issue and so does the article by Henry Broodney, Uri Shani and Aviad Sela which is re-published in this issue. The article, which reviews approaches for model integration, knowledge sharing and cooperation was presented at the international INCOSE 2013 conference and was awarded best paper of the conference.

The subject of system integration continues to be a major area of interest for system developers, and although it is well known that the end should be thought of before the beginning, the question of how to outline the right way to integration right from the beginning of the project always exists. The article by Dr. Meir Tahan, from Ort Braude College, which introduces how to do systems integration right the first time, was also presented at the INCOSE 2013 conference, as well as in INCOSE_IL 2013 in Israel.

Dr. Michael Maharik, a risk management and safety consultant with rich industrial experience in these areas, brings in his paper a comprehensive review of principles and priorities in managing safety risks. Besides being essential to every developer, this article is an important body of knowledge for the proper behaviour of each one of us in our multiple-risks world.

Yoav Gilad from Audocodes, who is also the coordinator of the Green Directive section in ILTAM draws our attention to the disturbing international problem about the sources of certain minerals used in the industry. Some of these minerals are produced, at the beginning of their supply chain, under slavery, abuse and enforcement of many people and children. Yoav points at the new regulations in this area, which the world (and especially Europe) is working to apply and enforce in the entire industry.

This issue is published at the beginning of a new year – 2014. Let this year be bledd with fruitful and enjoyable activity in all the areas of Systems Engineering in Israel.

I wish you pleasant reading.

I

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

The Voice of the Editor

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


II



Hello to the Israeli Systems Engineering Community,The year 2013 was full of events for the Israeli Association of Systems Engineering. The peak of those was the yearly conference, held on March 2013, which attracted nearly 500 participants. This year we firstly opened the personal membership track and the personal membership cards were sent to both existing and new association members. We conducted series of meetings, including a series of 5 meeting on “Systems Engineering as a profession” (2 times) and a 3-day seminar on Systems Integration (2 times). We conducted the first conference and a follow-up meeting on Simulation, two joint meetings with the Israeli Project Management Institution (PMI), a seminar on Requirements Identification and Elicitation, a seminar on Requirement Specification with Use Cases, a workshop on Risk Identification and a seminar on Product Families. The Risks workgroup and the Verification, Validation and Resilient workgroup continued their meetings. We started to prepare a series of 10 meetings on Systems Engineering in small and medium enterprises. We conducted a professional visit to the IBM Research Labs in Haifa. We also conducted many technical meetings, including a meeting on System Testing, a meeting (with a professional expert from abroad) on the relations between Systems Engineering and Project Management, a meeting on Systematic Innovative Thinking, a meeting on Systems Engineering Education and more. We participated in two conference days at the Technion-Gordon Institute for Systems Engineering.The main mission of the Israeli Association of Systems Engineering, INCOSE_IL, is to generate knowledge, distribute knowledge and share knowledge in order to advance the Systems Engineering in the Israeli industry, academy and government administration. Believing in the importance of this goal to the advancement of Israel’s society and economy we hope to keep this pace of events, and maybe even to increase it in 2014. On the one hand we will continue, and even extend, our activity for promoting Systems Engineering in companies who has been using it for many years, such as the large Defense companies. Beside the activity in our usual areas in these companies we will extend and deepen the dealing with complex systems and Systems-of-Systems. On the other hand, however, we set to ourselves a goal to deploy Systems Engineering methodologies, tools and techniques in civil small and medium enterprises. We also intend to satisfy other needs, such as Cyber, incorporation of Systems Engineering with Project Management and with Software Engineering, developing System Thinking and more.In order to succeed in our mission and to satisfy these ambitious goals we need active members who are willing to contribute their knowledge and experience to the advancement of Systems Engineering in Israel. Those who are interested are welcome to contact me personally through the e-mail address below.In addition, I call all the readers of “The Voice of the Systems” to join the association as personal members. The registration is free of charge for employees of companies who are ILTAM members, and also for academic personnel, students and IDF servers. The registration can be easily done on ILTAM web site and the registrants will receive their personal card, which qualifies for certain bonuses, such as receiving event information to their personal e-mail, receiving the “Voice of the Systems” journal by e-mail or by post, priority in registration to events with limited participation, full access to all the Systems Engineering information repositories of INCOSE_IL, discount in conference and seminar registration and reduced membership fees ($18 per year) for getting full access to INCOSE website. Join us to promote Systems Engineering in Israel.Sincerely,

The Voice of INCOSE_IL President

Prof. Moti FrankINCOSE_IL [email protected]


III



Systems of Systems Engineering –Do We Need a Paradigm Shift?

Summary of the Systems Engineering Day – 17.7.2013Organized by the Gordon Center for Systems Engineering

in commemoration of Dr. Zeev Bonen

AbstractSystems-of-Systems (SoS) Engineering is a new area in which systems engineers are investing their ideas and time. We report here about the main findings of a Conference Day, which was held at the Gordon Center for Systems Engineering at the Technion, in which the theory and practice of SoS engineering were presented by a variety of speakers.

The main conclusion of this day was that the System of Systems Engineering is not merely systems engineering for complex systems but is rather a real paradigm shift in systems engineering.

Keywords: System of systems engineering, Systems array engineering, Integration, Validation, Emergent properties, Innovation

IntroductionThe bi-annual conference day of the Gordon Center focused this time on the theory and practice of Systems of Systems Engineering. About 150 systems engineers and project managers from the industry and the defense system participated in the conference day, which was held at the Technion, in commemoration of Dr. Zeev Bonen. Shosh, Zeev’s widow, greeted the audience and declared that “commemorating Zeev at the Technion by a conference on Systems Engineering is the essence of his achievements”.

At the opening, Prof. Aviv Rosen, the head of Gordon Center and Prof. Moti Frank, the President of INCOSE_IL opened the day, which was organized in partnership with the Israeli Association for Systems Engineering (INCOSE_IL) and ILTAM.

System of Systems Engineering: Theory, Research and Applications for Renewable EnergyThe keynote speaker was Prof. Mo Jamshidi from The University of Texas, San Antonio (UTSA) who is experienced in research, lectures, publications and applications in the academy and the industry of systems of systems in various sizes. Prof. Jamshidi presented several definitions of SoS, such as: “A SoS is an integration of a finite number of constituent systems which are independent and operable, and networked together for a period of time to achieve a certain higher goal.”

Avigdor ZonnenshainGordon Center for Systems Engineering, Technion, Haifa, Israel

[email protected]


IV



He mentioned the Maier Principles (1998) for SoS Engineering:

• Operational independence of component systems

• Managerial independence of component systems

• Geographical distribution

• Emergent behavior

• Evolutionary development processes

SoS are characterized among themselves by:

• Technology

• Context

• Operation

• Geography

• Conceptual frame

Prof. Jamshidi presented examples of SoS from different domains, such as Defense and military, space, environment, renewable energy, healthcare, transportation, aerospace, claiming that systems engineering is already a well based discipline, and SoS engineering is still an opportunity that requires further investment in its design and formulation.

One of the subjects that he emphasized for development is the behavioral models of SoS. Prof. Jamshidi suggested that for this purpose we need to analyze Big Data – large amounts of information and data, and described several methods of doing that. He also indicated that we need to develop advanced simulation methods and tools for running the models.

Prof. Jamshidi raised the challenge of researching and studying the cloud computing as a System of Systems, proposing to develop Cloud Engineering in SoS approaches.

Systems Arrays Engineering – Systems Engineering for Unsynchronized SystemsMr. Eran Reuveni, the former General Manager of ITS-Israel, presented a research on Unsynchronized Systems Arrays Engineering which has been conducted at the Gordon Center by a team of researchers that included Mr. Eran Reuveni, Mrs. Miri Siton and Dr. Moshe Weiler. The research dealt with the development of Large Scale systems that takes place over time, among different parties with no common vision or goals, based on local interests. Despite the unsynchronized scenario it is expected that the entire array will function properly and will serve its goals.

The research suggested that the main solution for this challenge is to construct a “wise backbone” which will be used as a “glue” among the systems and enable the unsynchronized development and construction. The “wise backbone” was introduced in the research as Integrated System Interface, which has the following characteristics:

• Flexible

• Expendable

• Spatial Bridge

• Infrastructure for adaptors

The basic principles for unsynchronized development are:

1. Definition of the systems outputs in terms of the operational environment;


V



2. Continuous follow up on technologies maturity suitable for system solution and readiness to examine several solution directions at the same time;

3. Designing the integrated system architecture together with the solution developers;

4. Developing and constructing the interpretational infrastructure (the anchor backbone) for integrating the systems;

5. Building an integration environment for integration testing and compliance demonstration;

6. Managing a continuous spiral development process by a permanent directorate;

7. Integration in all five levels of architecture: Performance, business, services, information and technology;

8. The ability to accommodate both Bottom Up and Top Down development processes at the same time;

9. Continuous listening to emerging behaviors and new needs;

10.Mentoring services to new interesting parties who are joining the program in different time points.

Eran also demonstrated the unsynchronized system of the transportation system, which is being developed in stages from 2010 to 2040 in order to implement a transportation vision in a certain region.

Integrating Innovation Aspects in SoS EngineeringDr. Avi Galor-Ginzburg, VP of Elbit systems, presented a research he initiated at the Gordon Center on integrating innovation into the SoS engineering. Dr. Ginzburg is also the lecturer of the course “Man Made Systems” in the ME program for Systems Engineering at the Technion – a course which was planned and prepared by Dr. Zeev Bonen.

The research proposes that the main innovation elements will be introduced into the interfaces between the systems, in the interfaces methods and in the communication among the systems in such a way that there will be new and innovative contributions to current and new interested parties. Dr. Ginzburg also suggests to improve and innovate the development and implementation of SoS in the technical, operational and business aspects. He also recommends that the challenges of implementing innovation in SoS engineering will include, at least, the following elements:

• Formalizing the SoS innovation processes

• Procedures to handling independent systems with different stakeholders

• Optimization of different SoS solutions

• Promoting simulation of SoS

Implementing SoS in an Anti Missiles Defense SystemThe real implementation of SoS is a challenge for several companies. RAFAEL Ltd already implemented several SoS projects like Iron Dome and others.

Z.U. – a project manager in a directorate in RAFAEL, presented lessons learned from developing SoS engineering in a project of an Anti Missiles Defense System. He talked on behalf of I.P. the project manager who could not attend the Conference Day.

Z.U. presented the concept of the SoS and the main SOS engineering processes that are implemented in this project, such as requirements management, T&E plans and programs, and Simulations.


VI



A Proposal for Reducing Fatalities in Demonstrations (RFD) – A Student’s ProjectThe students in the course “Man Made Systems” are doing a project of tackling a real problem/challenge as an integral part of the course. The students Yuval Zeiler, Michael Simon and Leonid Glikin presented a project for Reducing Fatalities in Demonstrations ( RFD).

The proposed SoS is prioritizing the use of non-lethal tools in an optimal way, based on:

• Early identification of problematic events;

• Evaluation of the potential event’s severity;

• Understanding the needed tools for quiet handling of the demonstration;

• Information on all available resources.

The students presented the topology of the SoS and the way of communication in the SoS. In addition, they presented several algorithms which are applied in this SoS, such as an algorithm for prioritizing resources and an algorithm for analyzing pictures. The students also described several development processes, such as risks management, SWOT, market evaluation, partners search and identification, marketing plan and investment program.

The DANSE ProjectThe second part of the day was dedicated to the DANSE Project.

The issue of System of Systems Engineering is complex and important, and it requires learning and studying. There are a lot of unresolved issues, such as: How to integrate the systems into an effective SoS effectively? How to manage and operate SoS? How to tackle the complexity of SoS? Is there a “new” systems engineering for SoS?

The DANSE project [DANSE = Designing for Adaptability and evolution in System of systems Engineering] involves people and organizations from Israel, Europe and USA. It is a research effort to study this subject and develop innovative methodology for the challenges of SoS.

Project goalsDr. Michael Winokur from IAI, who leads the project in Israel, presented its goals: The DANSE project will develop a new methodology for the design and management of the operation of SoS, which:

• Supports evolving, adaptive and iterative SoS life-cycle model;

• Is based on formal semantics for SoS interoperation;

• Is supported by novel tools for analysis, simulation, and optimization.

MethodologyDr. Eric Honour from the USA, a senior partner in developing DANSE’s methodologies, described the main methodologies with emphasis on the breakthroughs.

The DANSE methodology includes the model for SoS creation, which consists of initiating the SoS, creating the SoS, and the life cycle of the SoS during the operational phase. In each of these stages there are cycles and iteration due to changes that are constantly introduced. This represents an internal learning process that is a critical element in the methodology of SoS creation.

At the system level it is proposed to implement the V model.

The general view of the proposed methodology is described below:


VII



In the DANSE project, there is an effort to promote the following aspects of SoS Engineering:

• SoS modeling ;

• Abstraction of constituent system models;

• Goals and contracts specification language (GCSL);

• Automated architecture generation;

• Joint simulation;

• Performance evaluation;

• Emergent behavior observation;

• Statistical model checking.

ToolsAs mentioned above, in the DANSE project there is an effort to develop a platform that connects all the tools needed to design and develop the SoS, including tools for modeling, analysis, abstraction, architecture, simulations, optimization, and statistical assessment. IBM’s Research Laboratories in Haifa takes active part in this effort in DANSE. Mr. Henry Broodney, who leads the systems engineering technologies in IBM-ISRAEL, gave an overview of the tools that are developed and offered in this framework. He especially described the platform connecting among the tools, as shown in the following figure.


VIII



ValidationAt the final stage of the DANSE project a validation of the methodology is planned by implementing it in several test cases and evaluating the findings. It is also planned to assess the users’ feedback on the usability and effectiveness of the developed methodology.

ConclusionsSystem of Systems Engineering is a paradigm shift in systems engineering, and not just systems engineering for complex systems. During this Conference Day we presented, demonstrated and discussed this trend in theory and application.

Dr. Avigdor Zonnenshain holds a Ph.D. degree in Systems Engineering from the University of Arizona, Tucson. Currently, he is Senior Research Associate at the Gordon Center for Systems Engineering at the Technion.Formerly, he held several major positions in the Quality and Systems Engineering areas.He is an active member of the Israel Society for Quality (ISQ), the leader of the assessment team for the National Quality Award for Industry and the chairman

of the standardization committee for management and quality. Dr. Zonnenshain is an active member of INCOSE_IL, chairing several National Conferences for Systems Engineering, leading several of its committees and publishing a lot of professional papers. He is an active member of INCOSE, highly involved in the International Conferences and several Working Groups and was elected an INCOSE Fellow in 2010.Dr. Zonnenshain is a senior lecturer at the Technion, the Israeli Technology Institute where he also guides students for higher degrees in quality, management and Systems Engineering.He is an active member of Lean SE WG and is leading in RAFAEL several systems engineering and project management processes improvements based on the lean principles.


IX



Model Integration – Extracting Value from MBSE

AbstractModel-Based Systems Engineering is making its way into the design processes of many Systems builders. But as with any new concept, it must prove its worth by demonstrating significant Return-On-Investment. One of the benefits of having designs formalized in models is sharing information, models and data, between designers and teams, and allowing valuable analytics to be performed over that collection of information. This paper will discuss a gradually evolving approach to model integration, sharing and collaboration, from simple indexing and relationship maintenance to comprehensive frameworks for information integration based on the recent advances in ontology-based data fusion and model transformations.

IntroductionThe usage of models for design has been around for some time. Naturally, for any existing task there would be competing tools with various systems builders wishing to exchange modeling data. Perhaps the best known examples of an approach are the mechanical STEP (ISO 10303) [11] standard and the electronic EDIF (IEC 61690-1) [24], but these examples are of homogeneous nature, exchanging information within the same domain with very well defined set of concepts, types and parameters.

Systems Engineering, addressing a vast mix of domains, cannot, even in theory, have a common denominator allowing similar exchange. Design, development, and manufacturing of many complex systems still employs best of breed tools that span across different dimensions such as Requirements, Architecture, Physical Modeling (e.g., Electrical and Mechanical), Software Development, Control Systems design, various analytic tools (e.g. simulation, verification, etc.), and last but certainly not least, the project management tools containing information about schedules, tasks, costs and other non-engineering information. In addition vast amounts of data (e.g. experimental data, product data, operational data) exists and is often utilized during design process. There is a wide acceptance of the fact that being able to leverage the knowledge of relationships, whether logical or mathematical, between all or some of the aforementioned information can bring great value to the systems development process, reducing costs and risks, improving designs and shortening schedules. At a core level, the enablement of this information integration relies on the very basic capability for the enterprise to handle the conceptual mappings (e.g. relations) between the various vocabularies being utilized by the plethora of tools and services being operated across all the dimensions. That is, some form of ontological mediation needs to be established as an intermediary resource that is

Henry Broodney, Uri Shani and Aviad SelaIBM Research, Mount Carmel 31905, Haifa, Israel

[email protected]

"Best Paper" award,INCOSE 2013 InternationalSymposium

First published in INCOSE 2013 International Symposium, Philadelphia, PA, June 24-27, 2013.

Copyright © 2013 by IBM. Republished in "The Voice of the Systems" with permission.


X



accessible across the enterprise to allow the free flow of information into the design processes, while making sure that information is semantically correct, unambiguous and valid.

However, every long journey must start somewhere and the first logical step is to allow the existence of links between various artifacts in the engineering ecosystem of a corporation, building a framework that can capture the existence of relationships, maintain them, and allow for change, version control and other important aspects of an information management tool on a corporate scale.

From Chaos to OrderAs discussed, the need for linking information between various heterogeneous tools has existed for quite a while and every corporation thus employs an assortment of commercial and home-grown tools to create relations from one design environment to another. The overall schema of such a situation is captured in Figure 1.

Figure 1 – Existing point-to-point mesh of tool integrations

The issues arising from such an arrangement are multiple. First of all, the collection of the point-to-point links is very difficult to manage as every link is a standalone application. Secondly, since each such application was created separately, an artifact, after going through a closed loop path (A→B→C→A), will not be equal to itself before such journey. Finally, any analysis that needs more than two tools as an input is not possible.

The solution to the problem uses a simple principle of utilizing a centrally managed framework of links (See Figure 2), creating a “hub-and-spoke” topology. This way the relationships information is retained in one single repository, enabling the assurance of consistency of the links, better management and most importantly the creation of value added analytics over the


XI



collection of links, for example traceability or impact analyses. Additional benefits may include cross-tool queries, document generation, rules checking, value added visualizations and more. An exemplary solution is the Rational® Engineering Lifecycle Management (RELM) [25] product from IBM. The solution uses a central query engine and employs OSLC (Open Services for Lifecycle Collaboration) [17] based adaptors to various tools to index their respective model information.

Figure 2 – Hub and Spoke approach

Beyond Linked DataWhile creating and maintaining the links between the various engineering elements’ models is useful, it still does not allow any model integration and sharing of model artifacts between designers.

If we consider the regular workflow of a project (Figure 3), we will see in the vast majority of cases that the heterogeneous domains are considered and viewed as a whole only in the first (architectural design) and the last (integration) phases of development. The prevalent approach is a “siloed” one, in which each stage of the design is primarily confined to a single phase and to a single company. In the intermediate design phases there are no formal connections between the models and the respective specialists are working on their domains (or subsystems), oblivious of the rest. And yet today’s environment requires massive coordination and information exchange, which can seem nearly impossible, given that many teams are geographically distributed both within companies and with outsourced suppliers. These interactions are highly document-based, controlled by legal departments, rather than


XII



engineering departments, and hinder collaborative engineering and cooperation throughout the design process. The integrative synchronization is therefore provided by teams of Systems Engineers (usually affiliated with the integrator), who communicate with the various teams analyzing the technical progress and making sure that requirements are fulfilled, interfaces are kept and everyone understood the specification (written in informal English) properly. With the rising complexity of contemporary systems, this human driven synchronization is not sufficient, as evident from many known cases of integration issues uncovered at the late project stage and being very costly to mitigate at that time.

Figure 3 – Model based design flow of a major product

The conclusion – models must communicate in a formal, semantically sound manner, without the human in the loop. For Systems Engineering to reach its maximum potential, a new system and infrastructure are needed to support co-engineering throughout the development ecosystem.

Model Integration ChallengesThe problem of model integration during design, development, testing, manufacturing and maintenance of complex systems has been a challenge for many years in the automotive, aerospace, defense, and electronic industries. Today, we see islands of integration (e.g., mechanical PDM, PLM systems) [3] [4]and efforts focused on cross-tool integration, in which tools from multiple vendors are made to inter-operate [5] [6] [7]. However, integration across physical domains (for example, electrical-mechanical) and across levels of abstraction (for example, physical layout and behavioral models in mechanical design) has not been achieved at a level that is sufficient to facilitate analysis and optimization at the entire system level. One difficulty lies in developing data formats that include information about these domains and that are compact enough to be handled with relative ease by tools. Another challenge is linking these different “views” in a mathematically coherent form so that analysis can be carried out.


XIII



Yet another is the support for versioning and configuration control so that different players in the supply chain can consistently access and manipulate these data.

This situation often results in fragile tool chains with no adequate public extension points, requiring considerable efforts in maintenance and evolution of the tool platform. At IBM, working with many clients in this area, we see numerous examples of information and activities being duplicated on the one hand, yet missing data on the other. We see structural breakages and inconsistent terminology hindering the consistent description of the product through its lifecycle, as well as fragmentation in its support process. We see legacy applications stitched together on the basis of rigid interfaces or monolithic subsystems with encapsulated functionality, causing increasing costs in application management, alongside a lack of agility and a strong dependency on monolithic solution providers.

The need for an open and standardized tool platform is not new. The industry invests much effort in defining common standards for system engineering methods, such as DoDAF [8] and ECSAM [9]. Additional standardization is carried out to support data exchange, such as the aforementioned STEP, which objective is to provide a mechanism for describing product data throughout the lifecycle of a product, independent from a particular system. The STEP standard is accompanied by other complementary standards, such as AP-233 [12], which describes data exchange for the system engineering community, and AP-239 [13], which handles product lifecycle support. Supporting standardization covers other aspects; ISA 95 (IEC 61512) [14] addresses assets, inventory, and work orders, helping to define product lifecycles, production capabilities and models, as well as schedules. ISA 88 (IEC/ISO 62264) [15] handles control system integration. These are just a sampling of related existing standards. We understand that the approach to the integration problem must enable flexible usage and accommodation of these standards, yet these standardization efforts mainly focus on the format, syntax, visualization, and sometimes schema of data exchange. Furthermore, these standardizations alone are not sufficient to satisfy the need for a technology that supports the complex supply chain system today’s companies require. While our approaches for new tool chains are born of the necessity for a common abstract semantic, we understand that a complete solution should be provided for several viewpoints supporting these standards.

At a core level, the enablement of such integration relies on the very basic capability for the enterprise to handle the conceptual mappings between the various vocabularies being utilized by the plethora of tools and services being operated across the aforementioned dimensions. That is, some form of ontological mediation needs to be established as an intermediary resource that is accessible across the enterprise to overcome the need to facilitate global reasoning in multi service provider environments.

Correspondingly, various architectures may be designed as a realization of such intermediary resource. Solutions may vary in terms of their topology (e.g., P2P vs. centralized), operation (e.g., runtime message monitoring vs. persistent-data analyses), and peer-dependency (e.g., peer-agnostic vs. peer-dependent). Any concrete architecture for such an intermediary resource has to be designed to effectively handle the aforementioned conceptual integration. Specifically, the developed architecture needs to satisfy the following key features:• Semantic-mediation – uniformly handle the correspondences between different

conceptualizations (namely, a ‘semantic layer’). • Heterogeneous views – support various projections over the semantic layer. • Flexibility – supporting episodic membership – enable anytime on/off boarding to

participating service and tools. • Data-ownership - preserving scattered information but yet enabling centralized data

querying.• Minimal peer-dependency - keeping vendor’s services agnostic to the integration –

semantic linking is instantiated on the server.


XIV



Semantic MediationModel Mediation allows engineering models created in one tool, using its own modeling language and internal representation, to be used in another tool having its own distinguished and different modeling language and internal representation. The Model Mediation which really works does not intend to solve the question what is the “lingua franca” of modeling, but to exploit that fact that all systems engineering modeling tools share one thing in common which is the management of models, and many other things in a variety of levels of commonality in the semantics of the models they manage.

As previously discussed, the current engineering practices normally postpone the verification of systems to the later (physical integration) project phase. Ontological Mediation and the semantic rigor it offers open the door for continuous analysis of various components with different models of computations that have been created by different tools and different teams. Future SE tool integration platforms should enable such continuous analysis.

A major undertaking in this direction is the SPRINT project [16] [26] in the context of the 7th Framework (FP7) Research Programme of the European Commission in which the authors of this work have the opportunity to participate.

We capitalize on both of these understandings; on one hand, we reach out to standard modeling representational syntaxes which are strong enough to represent any modeling content, and which have proven their effectiveness in the WEB, and which are commonly known as the “Semantic web” technologies and standard. Harnessing these technologies for systems engineering is in the working for several years now. Tools using these technologies are emerging as well as tools interoperability standards such as the OSLC (Open Standard for Lifecycle Collaboration) [17]. On the other hand, we propose to do models mediation of whatever is common among tools – be it small or large. We exploit this commonality via a technology we term “Semantic Mediation” which simply states the following: Given two different models in two different languages, but sharing a common representation (where the languages semantics have also a shared representation), a mechanism can apply mediation rules by which some common aspects of these models can be extracted and shared both ways.

Semantic web provides all the ingredients: RDF (Resource Description Framework) as the common models and semantics representation, OWL (Web Ontology Language) which also used RDF for the common semantic description of the models (their language), and model inference tools, rule-based engines and so on open-source tools to perform the mediation.

Using the IBM Jazz® platform, which compiled many of these open-source and standard tools of the semantic web into a single (though distributive) platform, and applied this successful technology also on the systems (and software) engineering tasks. SPRINT implements the model mediation on this platform and can demonstrate model sharing among few of the tools that have already been integrated with the SPRINT mediation server. Yet, the integration is not using point to point interoperability, or a full single common modeling language. Rather, the exchange of models is done in RDF format, and with the model having an ontology described by OWL. All mediation processing within the platform is governed by rules which are also written in RDF. Everything on that platform – models as well as ontologies – are in RDF, which can be browsed, queried, and be actionable by intelligent agents that can apply inferences to gain new knowledge and information from the existing models.

Jazz® and the associated tools have shown that RDF can serve effectively large modeling projects in systems as well as software. Therefore, we can trust that size and performance should not be the limiting factor when applying model mediation. Our initial steps show encouraging functional results and our goal is to continue and prove that this approach is feasible with effective tools which can do this.


XV



A System engineer often finds himself asking why it is so difficult to share common information among tools. Whatever the modeling tool of the many dozens of tools used for systems design, they all manage hierarchical structures. When eventually materialized, the models are related to a hierarchical bill of materials (BOM), and so on. Requirements, test cases, and other related artifacts which come from different tools have a lot in common. Model mediation seeks this commonality to allow sharing among the tools.

Some past experiencesAs previously discussed, many tool semantic integrations of tools are done on a point-to-point basis, where each such integration is relatively easy to implement, but the management of the interactions is virtually impossible, as is the creation of information continuity and consistency through several tools.

Several attempts were made to find the single common meta model that can express all other meta models of the involved tools. Exemplary attempts include the EU SPEEDS [19] and the DARPA META [20] projects. The resulting meta model (e.g. common semantics) proved too complicated to handle and the practical use was not achieved. This conclusion has also been established and acted upon in the CESAR EU [18].

Figure 4 – Point to point vs. common semantics integration approachesThe practical answer emerged in the concept of staged mediation.

Staged mediationFigure 5 depicts an exemplary structure of ontologies, organized in a graph based on their commonalities. The proposed framework is inspired by the aforementioned flexibility principle, requiring minimum mediation steps between the single tool and the mediation platform. Using this framework any new tool being introduced only adds one mediation step.

The example in the figure is a simple one, depicting tools that serve similar (albeit not identical) purposes. It is clear, however, that a totally different type of tool, for example a mechanical CAD tool, can also be supported by this framework. In that case the number of mediation steps will be greater. An additional and highly important point is that not all information will be transferred from one tool to the other. While with two SysML™ [2] based tools the transferred portion might be 90% and more, in the mechanical CAD case that portion may be much smaller, until a point that the only property of the model to be mediated will be the name of the developed block. Interestingly enough that will also provide great value to the end user, synchronizing the disparate roles (in this case the Systems Engineer and the mechanical designer) and creating the formal links between the models for later exploitation by various analytics mentioned in the initial chapters of this manuscript.


XVI



Figure 5 – Staged Mediation schema for selected tools

The detailed architecture of the semantic mediation framework is depicted in Figure 6. As previously discussed, a mediation flow may employ several mediation steps along the way. We distinguish between the actual single mediation step (Mediator - entities starting with the letter M in Figure 6) and the overall Container arranging these steps in the required order, keeping the intermediate artifacts and facilitating the mediation flow.

Figure 6 – Detailed Structure of Semantic Mediation platform


XVII



The mediators in that figure are associated with rules. For instance, MIA mediator has RIA document drawn above it. That is the set of rules which guides the mediation process. The same mediator can be used for many different mediation steps, employing different rules. Usually, rules will be OWL ontologies, defining equivalent classes and restrictions. One needs of course to understand that language to make use out of these capabilities. Yet, this is an expertise that spans over all mediation steps, and is not specific to Systems Engineering nor any specific tool – hence it may be highly reusable as much as the mediators. Following previous discussions, it should be noted that some information may be lost during the conversion due to the lack of suitable ontological elements in the target ontology to describe some elements in the ontology of origin. The SPRINT framework was built in a way allowing a complete delineation of the Container and the individual Mediators, not only due to considerations of the best practices in software architecture, but also to allow independent vendors to create specialized proprietary mediators without disclosing their intellectual property (e.g. the inner workings of the Mediator, its rules engine, language, etc.).

Notable related effortsThe EU iFEST project [21] has created approaches for specifying flexible tool structures and integration definitions, which can serve as complementary management and definition layer for the semantic mediation container. The structure of the container and the selection of specific mediators from a library may be automatically performed using the tool chain specification from iFEST.

The EU CESAR [18] (and CRYSTAL as its successor) has created a Reference Technology Platform for various industries focusing on tool integration and have explored the need for semantic integration layer. Semantic mediation, as proposed in this paper, can fill that need.

Example of Model MediationIn the SPRINT [26] project the exemplary mediation flow was performed between models in Rational® Rhapsody® [22] and Wolfram SystemModeler™ [23].

Figure 7 and Figure 8 depict the models and the subset ontologies of Rhapsody® and of SystemModeler™ respectively.

In our example we use 3 models and 2 mediation links. Two of the model languages are depicted in

Figure 7 and Figure 8. The first one is for Rhapsody® where a simple ontology defines a SysML™ model in a very straight forward way that aligns with the Rhapsody® model explorer. This ontology includes object parts of block types, each having its own block type, flow ports, flow specifications, etc. An example model (small though) is drawn as an RDF graph (graphically) below that screen capture.


XVIII



Figure 7 – Rhapsody® Instance Model

Likewise, we show the SystemModeler™ whose modeling language is Modelica®, and similarly to Rhapsody®, we show a model diagram (Figure 8), its model-explorer view, and the graph depicting that model as RDF.

A third model defines a simple hierarchical structure that is common to both of these tools’ languages. We call that “Basic Structure Ontology” (or BSO for short). We do not depict it here for lack of space, yet its role should be obvious. When Rhapsody® exports its model, that export triggers mediation from the Rhapsody® model to the BSO. As soon as the BSO repository is enriched with that model, mediation from the BSO model to the SystemModeler™ is triggered and a corresponding model similar to the one depicted schematically at the bottom of Figure 8 is created. That model is defined in the ontology describing SystemModeler™ RDF models so that that latter tool can import this model or any part of it into its own design space and continue working on it.


XIX



Figure 8 – SystemModeler™ Instance Model

The model export/import activity differs from OSLC by that models consist of many modeling element, and not just a single resource. That protocol also supports partial modifications and updates of the models and allowing for scenarios such as the following:

• Engineer A using tool A creates a model such as in Figure 7 (top).

• The model is shared via the model mediation platform with Engineer B using tool B.

• Engineer B adds a new component to the design in the language of tool B.

• Engineer B exports that new component to the mediation server.

• Engineer A is alerted (using – for instance – web PLM tools) of the new component. The component being mediated already has a resource identification which can be referenced over the web.

• Engineer A imports that component into his tool A and can work on it using his own familiar tool language and familiar desktop editing capabilities.

Another perspectiveThe engineering workflow described in the previous chapter implements the co-design use case, meaning the sharing of model elements, parameters and values between several engineers working on the same project (or a group of projects sharing common features).

An additional use case is that of engineering analytics. As mentioned in the introduction chapter of this manuscript, data plays a pivotal role in the contemporary design processes, shaping designs and influencing decisions. As more and more data is available, whether in the form


XX



of component information, test results or field data, it can be used to a great advantage in the design phase analytics, helping create better products and systems. Providing streamlined and effortless access to that data for engineers performing the analytics is a great challenge since the data lives in various tools and in various formats. Thus the new use case for semantic ontology based alignment.

The mechanics of such alignment are different, from the user perspective, than those of the co-design use case. The analytics process, whether a simulation, optimization, formal verification or else, consumes data. It is capable of requesting data that it needs in its own language (i.e. ontology). There is a need to be able to fill that request by finding the right data in the vast collection of interconnected tools and data bases, and performing operations on that data, whether semantic mediations (as described in chapter 5) or mathematical operations such as aggregation, averaging, etc.

Figure 9 depicts a potential high-level architecture of a semantic middleware platform that will be able to perform the task described above.

Figure 9 – Potential architecture of semantic middleware platform

Each source of data obviously has its own ontology, albeit it is not always clearly visible, since most data management tools are schema based. The mediators can also serve as the means of performing mathematical operations to make the data more suitable for its consumers (e.g. the analytics processes or engineers). Every potential data source will require an adaptor that will convert the schema based information to the ontology based representation required by the framework.

Additionally the proposed framework needs to add as little complexity as possible into the already complex ecosystem of systems builders. Thus the final framework should also include (in addition to the described mediation framework) a central ontology editing (and managing) tool, a tool for building and managing the adaptors to the various data and model sources, an interface to the various analytics tools, and a comprehensive management layer. The


XXI



average engineer will not be expected to understand how to customize the framework, but each organization will have power users that are capable of doing so. Since ontologies editing and query building skills are moderately easy to find nowadays, the proposed framework will be a viable business tool with immense positive value and Return-on-Investment.

Summary and Future DirectionsThis manuscript discussed the need for enabling value added interactions between the models from different tools on the level of links between the various engineering artifacts and also on the level of sharing model information between the tools.

It is the opinion of the authors that the future of Systems Engineering lies in facilitating the information flow between tools, allowing value added analytics across heterogeneous models, enabling engineers to exchange models ensuring synergy with each other, and leveraging the vast amounts of data to make the best design decisions possible.

Further potential direction involves exploring tool integration synergies with aforementioned EU funded projects such as CRYSTAL and iFEST.

AcknowledgmentsThe authors want to thank our SPRINT partners Daniel Hedberg from Wolfram Mathcore and Michael Wagner from Fraunhofer for their support and fruitful interactions.

References1. “Modelica Language Specification, Version 3.2”. Modelica Association. 2010-03-24.

2. SysML™ specification version 1.2. http://www.omg.org/spec/SysML/1.2/

3. NX PLM product development, Siemens, http://www.plm.automation.siemens.com/en_us/products/nx/

4. Product Life Cycle Management, Dassault Systemes, http://www.3ds.com/solutions/life-sciences/medical-device/enterprise-governance/new-product-development-introduction/

5. Zonghua Gu, Shige Wang, S Kodase, and K. G. Shin. An end-to-end tool chain for multi-view modeling and analysis of avionics mission computing software. In Real-Time Systems Symposium (RTSS), pages 78 – 81, 2003.

6. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, 2005. Available from:http://dx.doi.org/10.1007/s10270-004-0073-y.

7. Jie Liu, BichengWu, Xiaojun Liu, and Edward A. Lee. Interoperation of heterogeneous cad tools in Ptolemy II. In Symposium on Design, Test, and Microfabrication of MEMS/MOEMS, Paris, France, 1999.

8. DoD Architecture Framework, DoD Deputy Chief Information Officer, Available from : http://cio-nii.defense.gov/sites/dodaf20/

9. Jonah Z. Lavi, Joseph Kodish. Systems Modeling & Requirements Specification Using ECSAM: A Method for Embedded Computer-Based Systems Analysis. 11th IEEE ECBS04, 2004.

10.Dorit Nevo, Brent Fureaux, Yair Wand. Towards an evaluation framework for knowledge management systems. Information Technology and Management Volume 9, Number 4, 233-249 (2008).

11.NASA STEP Central , ISO 10303, http://step.nasa.gov/


XXII



12.Public and Private Information Portal, AP 233, http://www.ap233.org/13.Product Life Cycle Support (PLCS) , AP 239, http://www.plcs-resources.org14.Enterprise Control System Integration, ISA 95 (IEC 61512) , http://isa95.isa.org/default.aspx15.Batch Control, ISA 88 (IEC/ISO 62264) , http://www.isa.org/MSTemplate.cfm?MicrositeID=275

&CommitteeID=473716.SPRINT EU FP7 project. www.sprint-iot.eu17.Open Services for Lifecycle Collaboration. open-services.net18.CESAR EU project www.cesarproject.eu19.SPEEDS EU project http://www.speeds.eu.com/20.DARPA META www.darpa.mil/Our_Work/TTO/Programs/AVM/AVM_Design_Tools_(META).aspx21.iFEST EU project http://www.artemis-ifest.eu/22.Rational® Rhapsody®. www-142.ibm.com/software/products/us/en/ratirhapfami/23.Wolfram SystemModeler. www.wolfram.com/system-modeler/24.EDIF Standard for Electronics Data Interchange www.princeton.edu/~achaney/tmve/wiki100k/

docs/EDIF.html25.Rational® Engineering Lifecycle Management announcement, www.ibm.com/developerworks/

mydeveloperworks/blogs/invisiblethread/entry/relm26.Uri Shani, Daniel Wadler, Michael Wagner. Engineering Model Mediation Which Really

Works. INCOSE_IL 2013.

Henry Broodney is managing the Systems Engineering Technologies group at IBM Research - Haifa. Henry is an experienced Systems Engineer having dealt with wide range of disciplines in this professional career, ranging from architectural software development and electronic and chip design through complex mechanical design and heavy metal machining. He is fluent in contemporary Systems Engineering methods and tools, having both used current and implemented new methodologies in the various environments he has worked at.He holds an M.B.A and a B.Sc.EE., both from Technion, Israeli Institute of Technology.

Dr. Uri Shani is a Computer Science PhD, member of the IBM Haifa Research Lab since 1983 as researcher, team leader and a manager, working in a variety of areas, including storage, VOIP, software engineering, distributed systems, healthcare, UI and graphics, Telco BI, programming languages and systems engineering. Dr. Shani is responsible for the tools interoperability activities in the EU FP7 projects SPRINT and DANSE. Publications include a book and many papers in journals and conferences. Dr. Shani holds numerous patents, a Technion B.Sc. in Computer Science, and a University of Rochester (NY) M.Sc. and Ph.D. in Computer Science.

Aviad Sela is a member of Systems Engineering Technologies group at IBM Research – Haifa.His research experience includes several disciplines, ranging from signal processing, simulation and optimization and semantic web. Currently he is leading a research activity of ontology based knowledge integration for analytics.He holds B.Sc.EE and B.Sc.ME, both from Technion, Israeli Institute of Technology.


XXIII



Systems Integration – Do It Right First Time

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 and therefore helps to do the integration right first time.

IntroductionIntegration is a key process in the wider task of verification and validation of a system’s 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.

Meir Tahan, ESEP Ort Braude College, Karmiel, Israel

[email protected]

Published in INCOSE 2013 International Symposium, Philadelphia, PA, June 24-27, 2013

and in INCOSE_IL 2013, Hertzliah, March 4, 2013.

Republished in “The Voice of the Systems” with permission.


XXIV



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 first time. The paper suggests a “looking forward” methodology based on the well-known “V” model (INCOSE) for systems engineering.

Integration process considered successful when the integration team has all the tools required to detect and analyze the system improper behavior and easy to modify when changes implemented to the system.

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.

Integration ChallengesGeneralEngineering systems integration is inherently a process laden with uncertainties, problems and difficulties (Browning 1996 pp. 787–793; Buus et al. 1991 pp. 656–666; Power et al. 1996 pp. 3 – 9; Tahan and Ben Asher 2008 pp. 165–185). The following section reviews some common integration challenges.

Built-in Integration Issues. Engineering projects start with the customer’s 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


XXV



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 project’s 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


XXVI



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.

Looking Forward Integration Methodology

The Methodology BasicsFigure 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.

Actions at the Requirements Analyses StageAt 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”


XXVII



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.

Actions at the System Design StageGeneral. 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.


XXVIII



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. 459–462.):1. Big bang integration – Integrates all units in one step

2. Incremental Integration – Step by step integration using completed units

3. Adaptive Integration – Integrates units as they become available for integration

4. Bottom-up/Architecture Based – Integration by logical order

5. Top-Down – Building of a surrogate system, which is then replaced by available units

6. Functional/Phased Integration – Integration of the whole function


XXIX



7. Spiral Integration/Risk Oriented – Partial integration with non-completed units

8. 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

1. Parallel Integration – Dividing the system into several sub-systems and integrating them in parallel. Then integrating the integrated sub-systems to a complete system.

2. 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.


XXX



Figure 2. Graphical Presentation of the Looking Forward Methodology

Actual Use ReportUpgrading 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


XXXI



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 tester’s flexibility enabled monitoring this process. Finally, the two-year project was finished on time despite many unexpected problems.

ConclusionsA 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.

ReferencesBrowning, T. R. 1996. “Multi-Team Integration: Interdependence and integrative mechanism.” Paper presented at the Sixth Annual International Symposium of INCOSE, Boston, MA (US), 7–11 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), 7–11 July.

Sommerville, I. 2001. Software Engineering. Hoboken, New Jersey USA: Addison Wesley.


XXXII



Tahan, M., and Ben-Asher, J. Z. 2008. “Modeling and Optimization of Integration Processes Using Dynamic Programming.” Systems Engineering 11 (2):.

Dr. Meir Tahan, ESEP, 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 Technion–Israel Institute of Technology in 2001and a Ph.D in System Engineering from the Technion–Israel Institute of Technology in 2008. At 2012 Dr. Tahan certified by INCOSE as Expert Systems Engineering Professional (ESEP). 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.


XXXIII



On Risk and Safety: Principles and Priorities in Safety Management

Abstract

Risk is defined as the possibility of suffering injury, loss, or damage. It is a probabilistic phenomenon, characterized by two factors: the likelihood of an event that would cause harm or damage, and the severity of consequences should that event occur. Risk is never examined in isolation – it is always regarded in conjunction with the utility associated with some condition or process. That utility is not necessarily financial, nor tangible. The required level of utility, the tolerable level of risk, and the balance between the two are all different from case to case, from one individual to another, from one society to another, and from time to time. “Safety” can be defined as the degree to which risk is controlled and mitigated in the context of a given place or process. It follows that to increase the level of safety we must understand the risks involved, and pursue a deliberate process of mitigation.

This paper presents a terminology for discussing safety risks, and describes different aspects that experts and laypersons consider when analyzing risks and accidents; it then sketches out and prioritizes a number of high-level strategies to risk mitigation, and reviews some practical approaches for implementing these strategies, also in priority order. At each level the discussion is supported with examples from various real-world situations.

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

Michael MaharikIndependent [email protected]


graphic design studio MediaHut

http://www.iltam.org

mailto:iltam%40iltam.org?subject=

http://www.gordon-se.technion.ac.il

http://www.mediahut.co.il

Documents

ISSUE NO. 13 JANUARY 2014 - iltam.org · We started to prepare a series of 10 meetings on Systems Engineering ... industry of systems of systems in various sizes. Prof. Jamshidi