Integrating Concurrent Tool Set

Jane McKennon

Abstract

With the availability of commercial tools to automate the many different phases of the system life cycle, users are faced with the problem of integrating the information produced by one tool with the information required by another. The current state of the practice is for users to create paper or electronic document-based bridges between tools. The challenge is to create an integrated concurrent engineering tool set using engineering models, rather than documents, to transfer design information. An examination of the issues raised by integrating engineering tools leads to the conclusion that complete integration cannot be achieved by external mechanisms such as backplanes or by unilateral modifications to a single tool. Integrating multiple engineering tools requires changes to all tools.

Overview

The need for interfaces between tools supporting the concurrent engineering process has intensified as the complexity of specification, design, and construction of systems has increased. Figure 1 shows the two main aspects of the inter-tool interface: the type of linkage and the sophistication of the interface mechanism.

Figure 1. Aspects of the Inter-tool Interface

The type of linkage determines the fidelity of information transfer between phases of the design process. At the lowest level, Document Linkage, engineers communicate via English text documents; these documents may contain the results of engineering models, but the models are not passed to downstream engineers. The next level is Inter-Tool Model Linkage. Each group of engineers develops a model using a tool appropriate to its specialty, and an inter-tool bridge translates this model to a form that can be input to the tool used by the next group of engineers. Project Model Tool Linkage provides the highest fidelity information transfer. Because all engineering tools share a rich underlying modeling language, no model-to-model translation is required. Each group of engineers uses its tool to examine the shared model, does its engineering work, and passes the results back to the shared model.

Interface mechanisms determine the degree of automation and control of information transfer among tools. Flow Down is the lowest level interface; engineers can extract information from a tool and export it to a downstream tool, but there is no return flow of information back up the tool chain. Inter-Tool updates employ a backplane technology to enable tools to exchange information using automation to enable change control and to ensure integrity of shared information. With Project Model Tool Integration, tools share a rich and sophisticated modeling language; this allows the entire chain of tools to behave like a single integrated tool that varies the structure and availability of information depending on the phase of the design process.

With increasing sophistication of interface mechanisms, the work required to move information, control access, and provide data integrity becomes less and less visible to the user. Seamless, controlled information flow allows engineers, managers and customers to focus their time and effort on creating an efficient and robust model.

The Concurrent Engineering Process

The specification, design and construction of a large system is a very complex process. Evolution of a system design is sequential and iterative; it proceeds from mission analysis, through system requirements and design, to component design and implementation. Early in the project systems engineers postulate requirements and designs while component designers and specialty engineers evaluate and recommend changes. Later, component designers propose designs and receive evaluations from component developers and specialty engineers. When a problem is discovered that forces a change to a prior engineering phase, the design process becomes iterative. For example, a problem raised by component or specialty engineers may force a change at the system level, and cascade changes to all lower levels.

Application of engineering expertise is concurrent; all engineering disciplines participate in all phases of the design process. To promote accurate and complete technology transfer, some engineers work on several phases of the project or stay with it through its life cycle, but movement of personnel on and off the project leads to varying groups of engineers for each phase. Because of the complexity of the design process and the ever-changing population of the design team, completeness of data transfer and change management are necessary throughout all phases of the system design process.

Historically, the beginning and conclusion of each phase of a design is marked by the delivery and baselining of prescribed documents. Each group of engineers reads the documents passed to them by the preceding phase's engineers. They interpret the requirements and the model description in these documents in the context of the engineering specialty of the present phase of the design. The reinterpreted requirements, model structure, and a general knowledge of the system under construction are the basis for building the current phase of the system design. The conclusion of the phase is again marked by the delivery and baselining of the prescribed documents. Over the course of several translations, differences in interpretation can accumulate, causing dramatic differences between the customer's expectations and the behavior of the delivered system.

Modeling Tools

Different engineering disciplines have independently recognized the inadequacy of English text to communicate the interactions of complex systems. As each group developed its own compact graphical or tabular modeling language, tool companies sprang up to automate model construction and editing. Because the driving complexity of software was the management of huge amounts of data, software engineers developed data flow diagrams (DFDs) (see Figure 2) to trace the input, output, and storage of data. CASE tools quickly automated construction and editing of DFDs.

Figure 2. A Sample DFD

Software engineers soon recognized the need for a compact representation of control flow, and began to supplement DFDs with state machines and decision tables, which developed into control flow diagrams (CFDs). Similarly, other engineering disciplines developed their own notations such as VHSIC Hardware Description Language (VHDL) for chip design, and System Description Language (SDL) for telecommunications. Automated tools soon followed, such as Computer-Aided Design (CAD) for mechanical parts, and Computer-Aided Engineering (CAE) for electronic parts.

Systems engineers have traditionally used Functional Flow Block Diagrams (FFBDs) to provide a graphical view of system behavior as sequences, selections, and concurrencies of functions, that can be recursively decomposed into other FFBDs (see Figure 3).

Figure 3. A Functional Flow Block Diagram whose functions correspond to the bubbles on the DFD in Figure 2.

A number of systems engineering tools provide automated support for creating and editing FFBDs. While FFBDs show the possible sequences of system behavior, they ignore data flows, including those that trigger a transition from one behavior state to another. Like the DFDs and CFDs of a CASE tool, RDD-100^® Behavior Diagrams (BDs) [Alford 92] extend the FFBDs to represent both data flows and control transitions. The BD shown in Figure 4 indicates the same data flows as the DFD in Figure 2 and the same functions and control flows as the FFBD in Figure 3.

Figure 4. An Example Behavior Diagram. Discrete Items W, X, Y, and Z correspond to the data flows in the DFD in Figure 2. The control flow lines showing concurrency and conditions, plus the Discrete Functions A, B, C, D, and E, correspond to the control flows and functions on the FFBD in Figure 3.

Linkage Types

The number of tools used by the various engineering disciplines and the inefficiencies of manual information transfer beg for automated links between tools. The fidelity of the data transfer depends on the maturity of the linkage. Figure 5 summarizes the types of linkages and their strengths and weaknesses.

Maturity Level	Strengths	Weaknesses	Technology Availability
Document Linkage	Easy to achieve Uses existing document tool capabilities	Requires manual effort to translate model Errors magnified by reinterpretation of information	Many publication tools allow easy transfer to other publication tools
Inter-Tool Model Linkage	Requires only pair-wise tool cooperation Reduces translation effort and errors	Models only partially comparable Multiple translations allow errors to multiply	Usually requires some modification to at least one tool
Project Model Linkage	Eliminates translation effort and errors	Requires substantial investment to develop a purpose model and set of tools	Would require extensive changes to present tools, or entirely new tools

Figure 5. Comparison of Levels of Linkage Maturity

In a Flow Down, document-linked process (see Figure 6) each group of engineers delivers its documents on paper or in computer-readable form. The receiving engineers may use a scanner or translator to move the document into their text processing tool, or all engineering groups may adopt the same tool. In either case, the receiving engineers read the document and extract the pertinent subset of requirements to use as the basis for their design phase. They use these shared requirements as their originating requirements in the documents they pass on to the next level of design. Document Linkage superficially automates the hand-off from one group of engineers to another. Automating the transfer can save time and reduce re-keying errors, but it does not solve the communication problems that arise from repeatedly re-analyzing and re-interpreting engineering information. In addition, Document Linkage does not address transferring any model information that may be present in the documentation. While graphs and tables from a modeling tool may be included in later documents, the receiving engineers must manually translate those graphs and tables into their tool's modeling language to make revisions or extensions.

Model linkages transfer information as engineering models rather than as English text. Model linkages span a wide range of complexity, from partial translations between the models used by different tools, to the very high fidelity linkage achieved when all tools use the same model. In a model-linked process, documents are derived from models. They represent end products that explain the design at various stages, serve as conduits for model revision, and provide benchmarks for outside evaluators to measure design progress.

Figure 6. The Document Driven Engineering Process

In an Inter-Tool Model Linkage (see Figure 7), an automated bridge translates the information from the model used by one tool to that used by another. Well-crafted translations minimize information loss by finding acceptable semantic equivalents in one tool for the constructs of another. However, because the underlying models are different, the translations are not complete. The parts of the translation that cannot be automated are subject to human interpretation and human error. Also, since the translations only link pairs of tools, moving information from one end of the tool chain to another requires several translations. Even if each pair of translations is 80% complete, after three translations only 50% of the original information remains. The examples in the next section illustrate the difficulties of establishing a translation between models.

Model translations entail substantial programming work. It is easiest to understand, manipulate, and translate model semantics using the facilities within the tool that created the model. Some tools provide application programmer interfaces (APIs) to enable this access, but most do not. Unless both tools provide APIs, creating an inter-tool model link will require cooperation from the tool vendors.

Figure 7. Inter-Tool Model Linkage

Linkage via a project model eliminates translations. In a Project Model linked process (see Figure 8) all tools share a common model. Tools present semantically relevant views of the project model, showing or hiding information as appropriate to the engineering task they support. While such a linkage would eliminate translation problems, there is currently no model representation rich enough to support all engineering activities. Some existing model approaches such as DFD/CFDs and Behavior Diagrams could be extended to cover larger portions of the design process. Consolidation of the many models into a few general purpose ones would decrease the number of required inter-model translations. However, model consolidation requires a large investment to build sets of tools which are sufficiently fluent to work within a single consolidated model.

Figure 8. Project Model Linkage

A Model Translation Example: System to CASE

Accurate translations from one engineering domain to another are difficult to achieve. Moving models from systems to software engineering tools illustrates this challenge. Because most FFBDs do not show data flows, they cannot be translated into DFDs. The FFBD functions may indicate states that need to be represented in state machines, but they do not show what inputs trigger state transitions or what outputs are associated with states or transitions. A FFBD bridge to CASE could save considerable re-keying by passing function names in a data dictionary and even passing condition names as potential control inputs, but much of the control information in the FFBDs would be lost because it is not complete enough to allow automated translation. FFBDs do not support a model-linked integration with CASE tools.

The mapping from RDD-100 Behavior Diagrams (BDs) to CADRE Teamwork^® DFD/CFDs is much more promising, since each model provides data and control flow information. DFDs provide an infinitely decomposable hierarchy of Processes, with data flows into and out of the Processes. Unless otherwise specified, Processes act on data when they receive it. When it is necessary to explicitly turn Processes on and off, engineers add Control Specifications (C-Specs) to the DFDs. C-Specs represent controls as decision tables, state transition tables or state diagrams. States need not correspond to Processes. The events that trigger state transitions are special control flows, and the outputs can be special flows or the activation/deactivation of Processes.

Behavior Diagrams represent system behavior as functions, items, and the control structures the functions reside on. If an enabled function requires input, the arrival of a Discrete Item that can represent data or a physical object triggers the function. When triggered, a Discrete Function takes a specified time duration to transform its input Discrete Item into its output Discrete Items. When the function has been executed, the next Discrete Function on the control structure is enabled and, if necessary, waits for input before triggering. The sequence of Discrete Functions on a parallel BD branch, such as either of the branches (labeled P1 and P2) in the BD in Figure 4, forms an RDDProcess that can be represented as a Mealy state machine [Arbib 69] in which the Discrete Functions are the states, the input Discrete Items are the events that trigger state transitions, and the output Discrete Items are the actions that occur upon a state transition. There is no hierarchy of RDDProcesses; when RDD-100 encounters a process, it suspends the RDDProcess that is active and starts the new process as a separate RDDProcess at the same level.

The translation from BDs to DFDs is sufficiently robust to support a reasonable inter-tool model link. Because the RDD-100 and Teamwork models have very different views of their state machines, there is no obvious mapping of BDs to CFDs. Resolution of some theoretical control flow issues would permit this higher fidelity translation. Furthermore, the results of a proof of concept effort for translations of a system model to CAE (VHDL) suggest that a similar level of Inter-Tool Model Linkage to CAE is also currently feasible.

Interface Mechanisms

While linkage determines what is moved among tools, interface mechanisms determine how it is moved. Mechanisms include transfer methods, frequencies, and controls. They range in sophistication from simply taking a file produced by one tool and reading it into another, to establishing an integrated repository that provides access control and configuration management for all tools and supplies information on demand (subject to appropriate controls). The degree of data integrity depends on the quality of the mechanisms. Figure 9 summarizes the levels of mechanism sophistication and their strengths and weaknesses.

Flow Down represents the lowest level of mechanism sophistication and is relatively easy to implement. Most of today's tools accept file input, usually in a tool-specific format, such as CADRE CDIF, RDD-100 .rdt, or Interleaf^® ASCII Markup. Transfers can be made user-friendly by employing UNIX shell scripts or other command files, since most tools can be started by system command files or can execute their own command files. However, since most tools fail to provide effective access control, data integrity depends on scrupulous adherence to manual procedures. Unless the downstream tool provides access control and the transferred data is locked, engineers can change the transferred data so that it no longer matches the data in the upstream tool. Such unilateral changes can become embedded in a model, and can destroy traceability within the design cycle. Because Flow Down does not address the iterative nature of the engineering process, there is no automated way for downstream engineers to send proposed changes back upstream. Also, there is no mechanism for the upstream engineers to send only changes to the model or requirements downstream. If modifications are made to the design due to requested changes, these modifications must be installed manually in the downstream tool.

Interface Mechanism	Strengths	Weaknesses	Technology Availability
Flow Down	Easy to achieve Uses existing document tool capabilities	No way to ensure data integration	System command languages Tool-specific input formats
Inter-Tool Updates	Supports interative engineering process Some protection for data integrity	Requires decisions on which tool owns what data Requires access control and incremental updates	Most tools do not provide access control or incremental updates
Integration	"Seamless" information transfer	Requires either a backplane or substantial tool cooperation	Backplanes available to early adopters Tool supported integration requires major tool changes

Figure 9. Comparison of Levels of Interface Mechanisms

Inter-Tool Updates allow tools to update each other when information changes. Update integration supports an iterative engineering process. It also places significant requirements on the tools. As shown in the example in the next section, decisions must be made on how shared data is managed. While Flow Down integration requires only that tools accept file input, Inter-Tool Updates require that every tool keep track of which information can be changed in that tool, be able to export and import requests for design changes from upstream and downstream tools, and accept incremental updates from upstream tools. Due to the stand-alone origins of many tools, there has been little development of methods for specifying which data may be changed within a tool. Most contemporary tools do not have any basis for distributing or accepting incremental updates from other tools. In fact, the underlying inconsistencies between tool architectures can make incremental updates difficult or impossible.

One example is the problem of defining unique identifiers. RDD-100 identifies functions by unique, user-defined names, while Teamwork names its Processes automatically, based on their position in the DFD hierarchy. A change that adds or removes a level from a function hierarchy in RDD-100 has no effect on the identification of a function, while the same type of change in Teamwork will affect the name of every Process in the hierarchy below the change. This means that defining the changes to export from RDD-100 to Teamwork requires detailed tracking of changes to the entire model built in RDD-100 and may result in the re-export of many unchanged Processes, simply to guarantee that all levels of the hierarchy in Teamwork are correctly renamed. When some parts of the model are the responsibility of the systems tool, and other levels exist only in the CASE tool, incremental transfers can require considerable human intervention, since the CASE-only objects may require considerable renaming if there have been radical changes to the model hierarchy. While RDD-100 allows renames to flow down from a superior database, it does not provide a mechanism to propagate name changes among peers.

An important reason for moving beyond Flow Down integration is Change Management (CM). Properly designed CM protects the baselined design by facilitating control of changes in the design and of the dissemination of those changes. Recognizing when an issue must be returned to an upstream engineering level requires change control in the downstream level's tool. If the downstream engineering level requires a change in controlled information that originated in an upstream level of the design, the change must not be installed unilaterally in the downstream tool. Information passed from an upstream tool represents approved, baselined engineering that must not be changed without agreement from the ultimate decision makers - the customer, the change control board, the upstream engineers, etc. The downstream tool must allow only the creation and export of a request for the proposed change in the design that can be passed to the tool where the design originated.

Integration requires a unified mechanism to provide change control, configuration management, and information transfer. While highly cooperative tools could implement a unified distributed integration mechanism, less tool modification is required to use a central mechanism. Work in progress using a backplane to integrate system and software engineering tools suggests that Integration requires fewer tool modifications than Inter-Tool Updates. To work with the backplane, tools must cooperate with command files and accept incremental updates. However, programming in the backplane can provide change control and assure data integrity. In addition, engineers can use the backplane's transfer capabilities to package inter-tool file transfers in a user-friendly environment.

An Update Example: System and Document Tools

Documentation tools as well as modeling tools must accept updates. As models change, engineers revise documents, and information must pass in both directions between modeling and documentation tools. Aspects of document content, such as the page on which a model element appears, are often frozen at the first baseline and must be maintained in later revisions. To manage changes to document content, each model element must be associated with its position in each document. The documentation tool controls pagination. Either it must maintain the association between pages and model elements and place an updated element on the correct page, or it must pass page locations back to the modeling tool and be prepared to receive a page number with every model element. Current technology, as illustrated by the bridge from RDD-100 to Interleaf, does not support this level of integration. In the bridge, RDD-100 uses the document structure to extract model elements, assemble them into a document, apply some styling, and provide the styled document to Interleaf in ASCII Markup files. Users perform additional formatting in Interleaf® . Because RDD-100 passes an entire document to Interleaf, neither tool is able to associate page numbers with model elements. With this existing level of technology, complete document change management requires manual supervision of the change.

Conclusion

Current technology enables a high level of data integration without providing effective life cycle model linkage. While most projects are currently using one-way Flow Down tool interfaces, the emerging backplane technology promises tool integration without major changes to tools. Most current projects are primarily document linked, using Inter-Tool Model links when they are available. The benefits of model linkage are becoming well understood and are driving the demand for Inter-Tool Model links. It is likely that work is in progress on most straight-forward tool-to-tool translations that are not currently available.

There is no emerging "semantic backplane" to ease the next step in model linkage. Once the easy translations are available, it is likely that the engineering community will take a considerable amount of time to understand the deeper problems in model translation, and to pose effective solutions that make the models underlying diverse engineering tools more consistent. The integrated tool set of the near future will provide seamless transfer of text and translatable model information, but significant parts of the system model will be exposed to the interpretations and errors of human translation.

References

• [Alford 92] Alford, Mack, "Strengthening the Systems/Software Engineering Interface", Proceedings of the 2nd NCOSE Conference, July 1992.
• [Arbib 69] Arbib, Michael, "Theories of Abstract Autonoma", Prentice Hall,1969.

RDD-100 is a registered trademark of Holagent Corporation. Other product names mentioned in this document are trademarks or registered trademarks of their respective owners and are used for identification purposes only.