The Application of Distributed Systems Concepts to Systems Engineering Tool Integration David D Harris and Stephen C Cook Australian Centre for Test and Evaluation University of South Australia Levels Campus, Mawson Lakes, South Australia, 5095 AUSTRALIA ABSTRACT Within the systems engineering community there is considerable activity in developing support for the users of systems engineering tools who need to exchange data between different tools, in different locations, and across company boundaries. It appears that the bulk of this activity is aimed at minimising the manual work and errors that are currently incurred in one-off movements of system model data from one tool to another rather than seeing it as a fundamental, model-based view. This paper examines the requirements for distributed systems engineering tools, examines some current approaches and presents an alternative framework for distributed design based on having the system model distributed across the network of computers, tools and human participants. INTRODUCTION Modern civilisation is becoming increasingly reliant upon engineering systems that are becoming ever larger, ever more complex and ever more dependent upon integrated hardware and software interaction. The design and implementation of these systems is the domain of this paper. Systems design is becoming increasingly a global activity, carried out by geographically dispersed design teams that incorporate participants from wherever the required expertise can be found. Another feature of the design process is the interdisciplinary nature of the activity. It is becoming common practice to employ the concept of Integrated Product Teams (IPTs) to undertake concurrent, interdisciplinary systems engineering.

IPTs consist of members, each of which is normally an expert in a specific domain (a person), supported by a computer-based tool appropriate to that domain. When the participants are geographically dispersed, we refer to this situation as distributed systems engineering. Requirements for Distributed Systems Engineering Systems thinking (Checkland, 1981) can be used to provide insight into the system being engineered and the systems engineering process. Firstly, all systems form natural hierarchies where each level is identified by the emergent properties it displays. Systems are bound together within and between layers by communications and control. Thus it is a requirement that systems engineering tools pass the correct type information between themselves based on the hierarchical relationships between the elements of the systems being considered. If we consider distributed design to a human activity system then we need to provide tools that can support that process. It is now well recognised that top-down design needs to occur interactively in conjunction with synthesis. This is shown clearly in Figure 1 extracted from EIA/IS-632. Process Input Systems Analysis & Control

Requirements Analysis Requirements Loop

Functional Analysis and Allocation Design Loop Verification

Synthesis PROCESS OUTPUT

Figure 1: The EIA/IS-632 model of systems engineering process

SESA/INCOSE SE98 - 1

This process is repeated several times to cover each phase of the system lifecycle from concept definition through systems design and implementation to through-life support and eventual disposal. It is intended that the internal loops of each of these phases be iterated many times. Thus it is a requirement that there is bi-directional and frequent flow of information between tools working on the various levels of the design problem. An integrated environment for software development has been on the agenda of the softwareengineering world for some time (ECMA/NIST). The needs of systems engineers have been addressed by INCOSE (INCOSE TIIG), who set out to define the requirements of a tool data exchange mechanism for use by systems designers. The report addresses the concept of an Integrated System Engineering Environment (ISEE) and proposes a range of activities required by an ISEE Model. The INCOSE document is a report of its Tools Integration and Interoperability Working Group. It still takes a largely document-based view of systems engineering, but recognises that it must move beyond this. This report discusses seven data exchange scenarios with different sets of senders and receivers, and the different requirements for each. Scenario 1 describes the once-only movement of a database from one tool to another, while Scenario 7 covers navigation by team members through the full set of information available on all tools in the design team, which is a long step towards a fully distributed systems engineering environment. Design is a creative, culturally influenced human activity. It is strongly supported by information technology, which provides simplified and rapid access to a scientific base. In the end, the effectiveness of any designer support system must be judged from the perspective of the human designers who must use it. From this viewpoint, a distributed design environment is very different from the more traditional, paper-based methodology. There is a fundamental difference between today’s practices, of receiving a written specification, interpreting it, and then proceeding with the design on the basis of this understanding, and the distributed, network-supported process, where a design database essentially “arrives” in the tool database, and must be accepted as the framework upon which new design work is to be built. The receiving designer must be able to be sure that the integrity of the received design is assured, as

checking it could become so onerous a task as to invalidate the whole concept. In addition, the free flow of model data will allow for the possibility for frequent exchange of models between tools. Whether or not this is desirable from the point of view of the designer is yet to be established. However, lower levels of design information exchange will certainly proliferate, expanding upon today’s faxes, phone calls and meetings. The process is so different that work will need to be done to establish the best methods to use the newly available capabilities, and designers will need to be trained in their use. At present, a boundary exists between the prime contractor and sub-contractors, whether that subcontractor is internal or external to the organisation. This boundary is defined by a specification and carries contractual implications. The specification, forming part of the contract, defines what the prime passes to the sub, and what the sub must deliver in return. It also defines terms of payment for the subcontract activity. When direct exchange of model data between tools across such a boundary becomes simple, the integrity of the boundary is breached. The activity of the engineers, in using their new capabilities to implement engineering that is more “concurrent”, can very easily lead to a situation where what is being worked on can vary significantly from what was contracted. Different tools are used for different activities, so that each operates in a different “domain”. For example, one partner may use Tool A, which may be built around a state machine, and be used to construct models of system states and their transitions. Another partner may use Tool B that uses a hierarchical model without states. In this case, both tools recognise functionalities but one does not recognise a feature (states) of the other. Some data can therefore be transferred between them, but there will be other data that cannot be communicated. Figure 2 shows this situation in the form of a Venn diagram, indicating that only data that is common between the two representations can be communicated. Clearly, if the two domains are similar, most of the model data can be communicated. If there is no overlap then no communication is possible.

SESA/INCOSE SE98 - 2

Domain of Tool B

Domain of Tool A

Figure 2: Intersection of tool representations Using tool data transfer to communicate model data between designers and their tools introduces a totally new method of working. This is illustrated in Figure 3.

Existing

Spec Tool A

Tool B

New Figure 3: System model transfer concepts Under the existing methodology, that part of the design, prepared in Tool A, which is to be developed by the subcontractor using Tool B, is transferred in the form of a specification, either on paper or as an electronic document, but not as a model. The designer using Tool B reads the specification until he understands it, and then uses Tool B to construct a model implementing the specification requirements. Under the new methodology, the designers using Tool B does not (necessarily) see a specification. The model simply arrives within the database of his tool. He must use any method available to him to understand the model and what it is intended to do. At least two major issues arise Model integrity: Under the existing system, the tool-input mechanisms used by the designer perform a check function to validate the input. Under the new methodology, any such checking must be performed by the tool import interface, and the designer must

simply accept that it has been done. This has long been an area of difficulty in the transfer of CAD models and must be expected to show up again in system model data transfer. Model comprehension: The designer using Tool B is faced with a model that he must now learn about and understand. Most tools have capabilities for moving parts of the model around (so that, for example, connections can be clarified) and for checking logic, function and data flow. However, these capabilities will need considerable development and enhancement to work under the new methodologies. The management of the configuration of the system, including authority for design activities, version control and change control also increases rapidly in complexity as the number of designers contributing concurrently to the developing system increases. It is imperative that configuration management under these circumstances is managed automatically by the system. These few words simply point to a major issue that arises with distributed design activities, but will not be discussed further here. Some Current Approaches The exchange of design data between design engineering tools in some domains has become almost routine. Arriving at this situation has, however, been difficult and has taken time to allow for the changes necessary to database representations and the tools incorporating them. Taking the example of mechanical engineering Computer Aided Design (CAD), and confining attention to 3-D models, the representation of the model may be in wireframe, surface model or solid model, and there are several methods for representing each of these. In the case of solid models, the methods of representation in use have come down to two Constructive Solid Geometry (CSG) and Boundary Representation (Brep). Many solid modelling CAD tools use both. Data exchange mechanisms between tools also appear to have come down to two leading systems IGES and STEP. Each is now standardised, and virtually all CAD systems have the capability to use one or the other, or, usually, both to exchange data with other CAD tools. These systems also allow the exchange of data with other non-CAD tools (such as Finite Element Modelling tools). In this domain, we can see two characteristics:

SESA/INCOSE SE98 - 3

•

The battle for the “hearts and minds” of tool suppliers has been won. No one would now market a tool that cannot exchange data with others using the standard exchange mechanisms. • There has been a convergence in both directions a reduction in the numbers of representation schemata used in CAD tools, converging with a reduction in the number of exchange standards supported. In the case of systems engineering tools the capability to exchange model data is still in its infancy. The only significant standard used is CASE Data Interchange Format (CDIF) and, as its name implies, this has emerged from the Computer Aided Software Engineering (CASE) world. One CDIF derivative, developed by the Cayenne company primarily for use with their TeamWork tool, is available. It is based on a 1994 standard, and has been extended to suit the tool. Nevertheless, where System Engineering tools have a data exchange format it is usually Cayenne CDIF. As data exchange between system engineering tools is so limited, a common approach today is to avoid the problems by eliminating the dispersion of the design teams. Collocation of teams for considerable periods of time is common practice, bringing all the benefits of face-to-face communication together with the ability to work on common tools and tool sets. Even in the realm of CAD, there is pressure towards the use of common tool sets, as data exchange between different tools still often introduces problems. Other activities used to overcome the tyranny (and cost) of distance include video conferencing, and Computer Supported Collaborative Work (CSCW) tool sets. THE SEDRES PROJECT As the European Union moves toward closer integration, there is increasing pressure for collaboration between companies operating in different countries. A group of the major aerospace companies of Italy, France, Britain, Germany and Sweden formed a consortium with three Universities to address the issue of system engineering tool data exchange. In 1996 the consortium was supported by the Commission of the European Community under the “ESPRIT” grant scheme, and the SEDRES Project was born. SEDRES (System Engineering Data

Representation and Exchange Standardisation) set out to define a standard for use between system engineering tools for exchange of system model data. A good description of this project is provided in Johnson, (1997). The SEDRES Consortium agreed to accept the definitions of System Engineering as set out in the IEEE 1220 standard, and to confine its attention to tools used to represent system function and behaviour. It set out to investigate the requirements for such data exchange through the study of a series of “Use Scenarios”. Each Use Scenario was set up to represent a “prime contractor - subcontractor” relationship, with the prime supplying to the sub a high level design, some aspect of which the sub was required to elaborate through detailed design. Critically, the sub was then required to pass the detailed design back to the prime for re-incorporation into the high level model. Different companies play different roles in different use scenarios, using different design tools. The Use Scenarios were approached in two stages, incorporating different levels of capability in the exchange mechanisms. The initial level of capability (Capability/1) covered, essentially, functionality. Capability/2 will extend this to behaviour. The work of Capability/1 is complete at the time of writing, while Capability/2 testing will occur late in 1998. The SEDRES Consortium examined the CDIF standards and concepts (which are under active development by a very active group of organisations) and came to the conclusion that CDIF was unlikely to be able to provide the full functionality they sought. This was essentially due to the software focus of CDIF and the hardware/software focus of SEDRES. The decision was then made to base all the prototype interfaces developed by the SEDRES Group on the STEP standard, and the SEDRES system has now been accepted as a New Work Item within the ISO STEP standardisation system. A key issue throughout the SEDRES Project has been the development of a data model upon which the exchange standard is built. This has been the responsibility of the Computer Science Department of Linköping University (one of the SEDRES partners). The range of tools used, and the companies using them, is shown in Table 1. There is no implication that these tools have any particular significance for the data exchange of the SEDRES Project - they were simply available within the partner companies.

SESA/INCOSE SE98 - 4

Tool StateMate TeamWork CoRE StP SCADE/A SA MatrixX WorkBenc h

Supplier i-Logix Cayenne British A’space Aonix Verilog

Company British A’space DASA British A’space

ISI SES

British A’space Aerospatiale

Aerospatiale SAAB

Table 1 SEDRES findings The SEDRES Project is not yet complete, but the Capability/1 results are in. At this point it can be stated that: • A data model has been developed which demonstrates that exchange of systems engineering model data between the set of different tools selected is feasible and practical. • A draft standard has been prepared, based on the STEP standard system and the SEDRES data model that forms a practical basis for exchange mechanisms for use with systems engineering tools. • Model data has been exchanged between systems engineers in a way that has allowed the receiving engineer to use the model as the foundation for extended work on the system. In other words, the SEDRES work to date appears to offer promise, and has demonstrated that, within the range of tools and capabilities investigated, model data exchange appears feasible. A FRAMEWORK FOR DISTRIBUTED SYSTEMS ENGINEERING The concept of distributed systems is widely accepted within both systems engineering and software engineering domains. However, the concepts are still not widely employed in the creation of these systems. This issue becomes more important as systems engineering becomes a global activity, and (possibly geographically dispersed) Integrated (or Interdisciplinary) Product Teams (IPTs) become increasingly important in the creation of engineering systems. A new framework is required to support this activity. Rather than consider the transfer of information between tools, an alternative is to

consider the system model itself as being distributed over a network, with individual tools being used to access the network model rather than attempting to create their own version of the system model. The concept proposed comprises three elements: 1. A network of tools, with their human users, which together hold the system model. The network holds a system of “pointers” to the tools, their contribution to the model, and their capabilities in providing this contribution. This system of pointers provides both configuration management and access management for the model. 2. A system of “blackboards” that are used for temporary tool-to-tool (and user-to-user) negotiation. The results of these negotiations will eventually come under the umbrella of the configuration management of the system under development. 3. A range of agents that have several functions, including: • resource location to identify tools and sources of required information; • remote execution of network tools to extract information required by other users; • support for computer-supported human user negotiation. The network model frees the tool developers from one of their most common, and most onerous, tasks the creation of interfaces between their tool and other tools. The network model is made possible by middleware technologies, such as DCE, CORBA and Java, currently emerging from mainstream computer science research (OSF, 1992; Coulouris et al., 1994; Raymond and Armstrong, 1995; IEEE, 1996). The characteristics Coulouris ascribes to middleware will all be needed to realise the distributed systems engineering development model, namely resources sharing, openness, concurrency, scalability, fault tolerance and transparency. The distributed model appears to provide a way out of the major difficulties currently confronting the tool community in moving towards the greater support of distributed IPTs. It is recognised, however, that major problems exist in realising this ideal and there is reason to believe that, for some time, there will be significant combinations of useful tools for which this interfacing may not be possible. Nonetheless, much can be achieved and the technology to realise the distributed design model is

SESA/INCOSE SE98 - 5

rapidly maturing. One of the key ideas is the use of a distributed blackboard, as described below.

for example, by direct communication with each other, excluding other team members), then this system is analogous with the blackboard

A DISTRIBUTED BLACKBOARD MODEL The concept of a “blackboard” for the collaboration of a series of networked agents is based upon the fundamental work of (Nii, 1989) and extended to consideration of a system design (in this case, a measurement system) in (Harris and Harvey, 1994). Quoting from this paper: “The metaphors for the blackboard concept are based on co-operative problem solving and the most common metaphors are based on a group of experts solving a problem… (This) reflects the idea of a group of specialists co-operating in the solution of a problem; they do not communicate with each other directly but write, on a central blackboard, items that their expertise allows them to see as directly relevant to the problem at its current stage of development. Any expert may use the information on the blackboard to work towards a solution or partial solution of the problem at hand.” Looking at the members of a design team (where, as previously stated, a “member” is a person with a computer-based tool), their activity can be shown diagrammatically as in Figure 4 model.

Developing System Model

Figure 4: An illustration of system design using a common model Whether they are sitting across a meeting table or are in different countries, their contribution to the developing system model will be via their computer models of that aspect of the model that is of interest to them, and in a form that can be represented by their tool(s). If the individual team members draw their information only from the common model (and not,

Each team member is only interested in aspects of the model that can be represented within their tool. Anything that cannot be represented, as indicated in Figure 2, cannot be communicated. As the “team member” includes a person, this restriction is not absolute, and the human capability for investigation, understanding and common sense is critical to the function of the process, but from the point of view of tool design, we can use the pure blackboard analogy. The blackboard will hold the functionality of the system - those things that the system can do. A team member can then access those functions that are visible to it. If we move to Behavioural aspects of the system (how it does its functions, time effects etc) it would appear that these would not be available on the blackboard but in the team members and, in particular, in the models held in the tools they use. Taking this a step further, there needs to be no developing system “model” located in any particular place. If a team member wishes to access the functionality of the system, this can be done by querying the blackboard, which can point to members from whom this can be obtained. If the team member requires information on behaviour, this can be done by stimulating another member, where the appropriate behaviour model is held, and obtaining a response. Of course, these queries, stimuli and responses can cover multiple members, and in effect, provide a full modelling and simulation capability for the system at its current stage of development. Blackboard systems were originally envisaged for tackling difficult problems that required many agents, either human or artificial. We are proposing to extend that model by having the blackboard distributed across the network. While this requires the use of the rapidly emerging distributed systems technology, there already exists middleware products that can support network-wide information extraction, remote procedure calls, resource broking and seamless network-wide transparency. CONCLUSION This paper presents a conceptual architectural framework for distributed computer-aided systems engineering. The approach is to avoid the problems of model translation by keeping the model of each

SESA/INCOSE SE98 - 6

aspect of the system within the tools on which it was developed. Access to the model can be facilitated by either human-human communication and humandirected information transfer or in a more fully developed implementation a blackboard system supported by middleware. A mature design system of this type would be able to encompass all conceivable tools and be able to run on a wide range of computing platforms.

Sept 1997, Frankfurt Germany, pp 92 - 107. Direct Communications GmBH, Berlin. 12. Nii H P, “Blackboard Architectures and Applications” Academic Press Inc, 1989. 13. OSF, “Introduction to DCE”, Open Software Foundation, Prentice-Hall, New Jersey, 1992. 14. Raymond K and Armstrong L, “open Distributed Processing - Experiences with distributed environments”, Chapman & Hall, London 1995, ISBN 0 412 71150 8.

REFERENCES 1.

Allison J S and Cook S C, “The New Era in Military Systems Thinking and Practice”, Internal Report to DSTO, Australian Centre for Test and Evaluation, University of South Australia, 1997 2. Boardman J, “SERF Report”, SERC, De Monfort University, Leicester. 3. Checkland P. “Systems Thinking, Systems Practice”, Wiley, Chichester, 1981. 4. Coulouris G, Dollimore J and Kindberg T., “Distributed Systems - Concepts and Design”, 2nd Ed., Addison Wesley, 1994. 5. DERA, “Systems Engineering has Promising Future“ DERA News, p16, January, 1998. 6. ECMA/NIST Report “Reference Model for Frameworks for Software Engineering Environments” Edition 3 of Technical Report ECMA TR/55; NIST Special Publication 500211, August 1993. 7. Harris D D and Harvey J G, “Tailoring the Blackboard Concept to produce a flexible, extensible Knowledge-based Design Tool”, Knowledge-Based Systems 9 (1996), 233-243. 8. IEE, “Building Integrated Systems”, IEE, London, May, 1997. 9. IEEE, “Proc of the Fifth IEEE International Symposium on High Performance Computing, IEEE Computer Society Press, Los Alamitos, California, ISBN 0-8186-7582-9. 10. INCOSE TIIG Report “Tools Integration Interest Group Report: Scenarios leading towards a concept of operations for an integrated systems engineering environment”, Proceedings, INCOSE ’97 conference, Los Angeles, July 1997. 11. Johnson JFE, “The SEDRES Project, Extending STEP from structural definition to product functionality” Proc 8th International Conference on CALS and Electronic Commerce in Europe,

ABOUT THE AUTHORS David Harris Mr Harris graduated in mechanical engineering from the University of Western Australia in 1960 and, following 3 years in the aircraft industry in the UK, joined Chrysler Australia, in Adelaide. Here he held a number of positions including design engineer and quality assurance manager. During this period he gained a Graduate Diploma in Business Administration from the South Australian Institute of Technology. He left the automotive industry to take up a position with the Australian Design Council, and subsequently undertook consulting in mechanical product engineering. In this role he was an early user of mechanical CAD/CAM in a range of product design projects, leading to the development of special purpose CAD tools for the design of ophthalmic lenses. In 1990 he joined the University of South Australia, and has since held a number of Business Management positions with research groups of this University. With Prof Peter Sydenham, he was a founder of the Australian Centre for Test and Evaluation (ACTE) in 1994 and currently holds the position of Business Manager with ACTE. He gained a MEng in Test & Evaluation in 1997, and is ACTE’s research leader on the SEDRES Project. Stephen Cook After graduating in electronics engineering from the South Australian Institute of Technology in 1977, Prof Cook commenced work as a telecommunications equipment design engineer in the UK where he also completed an MSc in computer science at the University of Kent. On his return to Australia, he worked in the defence electronics industry until 1988 when he joined the Defence Science and Technology Organisation (DSTO) as a Principal Engineer responsible for radio communication research. In addition to his management role, he became an active

SESA/INCOSE SE98 - 7

contributor to the fields of radio system performance monitoring, high frequency radio systems design, multi-mechanism adaptive radio technology, modelling and simulation of military information networks, and engineering design automation. Prof Cook completed a PhD in 1990 in systems engineering at the City University London. In 1994 he was promoted to Senior Principal Research

Scientist responsible for the management and scientific leadership of the Military Information Networks Branch of DSTO. Prof Cook joined the University of South Australia as the foundation Professor of Systems Engineering in 1997. Prof Cook has contributed to three books and has published over fifty refereed journal and conference papers.

SESA/INCOSE SE98 - 8