# Presentation: 829982

## An Overview of AP233STEP’s  Systems Engineering Standard  for theAerospace PDE WorkshopApril 8, 2003Jim U’RenAP233 Working Group ChairNASA / JPL

## The SEDRES Project:The Roots of AP233(Systems Engineering Representation and Exchange Standardization)

**SEDRES Project consists of European aerospace companies**
**Aerospatiale, Alenia, British Aerospace (now BAE Systems), DASA (now DaimlerChrysler), SAAB**
**Joint projects**
**Gripen**
**Eurofighter (EF2000)**
**Project focused on specific SE data exchanges**
**SEDRES initiated NWI in TC184/SC4 in 1998 to provide a means of publishing its work**

**Notes:**
During the early 1990’s, in the context of a number of joint projects, and prompted by the need to improve the systems engineering process, the companies identified design data exchange as a fertile topic for joint research work.
In addition some companies had previous done limited prototyping of neutral data exchange, or were actively pursuing such approaches in other domains, such as structural design activities.
These discussions led to the formulation of the SEDRES project proposal to the Framework IV funding round of the European Commission. The following slides elaborate on a number of the business issues that provide elements of the business case to supporting developments towards neutral data exchange.

## Primary Driver: Reduction in Tool Interfaces

**Notes:**
Achieving a standards-based way of exchanging design information has the critical benefit of dramatically improving the development/maintenance cost situation for environments which need many design tools. This is the usual (N(N-1) versus 2N argument.
Additionally, the establishment of standards-based design data exchange is a stepping stone on a longer path to achieve neutral design repositories where individual design tools can put information in and out of such repositories as required.

## SEDRES Project Concludes

**Deliveries:**
**Produce an EXPRESS data model**
**Prototype data exchanges between commercial tools**
**Initiated AP233 Work Item in TC184 / SC4**
**Produce a ISO Publicly Available Specification - PAS 20542 (in work)**
**SEDRES Project Final Review - December 2001 at  BAE SYSTEMS (Warton, UK)**

**Notes:**
This is self explanatory.

## AP233: The Next Development Wave

**A change in scope - integration and communication of SE information**
**PDES Inc., (with INCOSE and OMG) leads the next wave of AP233 development**
**Using lessons learned from PLCS and other STEP initiatives, AP233 is planning a“fast moving” project that develops standards-based technology**

## Systems Engineeringa “big picture” definition

**“ *****An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability*****.”**
-                                                      (IEEE 1220-1984)

## Planned AP233 Module Sets

- Requirements
- Structural Models
- Behavioral Models
- Validation and Verification
- Data Representation
- Risk Analysis

- Analysis Interfaces
- Scheduling
- Cost Models
- Organizational Structure
- PDM
- Security
- Rules

**Notes:**
AP233 Module Sets 
The following identifies and describes the Module Sets for AP233, the STEP Systems Engineering Project. 
Requirements - a data model that describes requirements as text strings with traceability, allocation, weighting and risk identified with each requirement [Text-based Requirements ( TBR ) ] and that describes requirements as structured and quantified formalisms that maybe decomposed from text-based requirements; can include tables, spreadsheets, graphs, charts, pictures and equations [ Property-based Requirements (PBR) ]. 
Structural Models - a data model that describes how a system is built; defines the static relationships among  the subsystems, components, or parts that actually constitute the system; describes what is designed, built and maintained; contains specifications for design, manufacture, and maintenance and information about actual manufactured parts and their verification and maintenance.
Behavioral Models - a data model that describes how a system performs; includes functions, inputs, outputs and control operators which define the ordering of functions; the model describes Functional Flow Block Diagrams, Finite State Machines, Causal Chain, Data Flow Diagrams and Sequence Diagrams.
Validation and Verification Model - a data model that describes the plan, infrastructure and status of validation and verification processes.
Allocation Model - a data model that describes structures necessary to allocate requirements, schedule, costs, risks and other functions associated with a body of work.
Risk Analysis - a data model that identifies risk(s), describes their status, specifies relationships, likelihood, consequence, impact approach strategy and contingencies. [ may collaborate/reuse PLCS Risk Model ]
Cost Models - a data model that describes direct, indirect, fixed, variable, material, administrative, finance, and contingency costs; provides linkage to system product structure(s)
Data Representation - "a consistent set of “presentation mechanisms” and “advanced schematics product model definition”, which is designed to present the computer sensible model data (defined in representation model space) onto a human understandable schematic diagram (presentation space), conforming to conventional and/or future draughting standards" [ from Intelligent Sematics PWI RDD ] [ may include features from AP221 and AP212 ]
Scheduling - a data model that identifies activities, dependencies, durations and milestones associated with products described in the WBS; includes WorkFlow Diagrams, Network Schedules, Gantt Charts and Resource Leveling. [ work with PLCS ]
Work Breakdown Structure - a data model that represents the structure used to represent the pieces of work necessary to complete a project.  [ work with PLCS ] 

PDM - a data model that extends the STEP PDM Schema and PDM Modules to electro-mechanical, system engineering, product life-cycle and other non-physical domains.  [ work with PLCS and PDM ]

Security - a data model that describes project, organization, country and user defined security levels as well as user authentication and intellectual property.  [ work with PLCS and PDM ]

Organizational Structure - a data model that provides relationships, functional roles, skill qualification and documentation that defines an organizational structure.  [ work with PLCS ] 
AP Interface Models - a data model that describes the interfaces between domain specific data models such as mechanical, electronic, structural analysis, thermal analysis, manufacturing, etc. [ work with other STEP AP groups ]

## AP233 Module Sets

**Text-based Requirements [ TBR ] - a data model that describes requirements as text strings with traceability, allocation, weighting and risk identified with each requirement**
**Property-based Requirements [ PBR] - a data model that describes requirements as structured and quantified formalisms that maybe decomposed from text-based requirements; can include tables, spreadsheets, graphs, charts, pictures and equations**
**Structural Models - a data model that describes how a system is built; defines the static relationships among the subsystems, components, or parts that actually constitute the system; describes what is designed, built and maintained; contains specifications for design, manufacture, and maintenance and information about actual manufactured parts and their verification and maintenance**

## AP233 Module Sets (cont.)

- Behavioral Models** - a data model that describes how a system performs; includes functions, inputs, outputs and control operators which define the ordering of functions; the model describes Functional Flow Block Diagrams, Finite State Machines, Causal Chain, Data Flow Diagrams and Sequence Diagrams**
- Data Representation** - "a consistent set of “presentation mechanisms” and “advanced schematics product model definition”, which is designed to present the computer sensible model data (defined in representation model space) onto a human understandable schematic diagram (presentation space), conforming to conventional and/or future draughting standards" [ from Intelligent Sematics PWI RDD ]**

## AP233 Module Sets (cont.)

- Risk Analysis** - a data model that identifies risk(s), describes their status, specifies relationships, likelihood, consequence, impact approach strategy and contingencies**
- Cost Models** - a data model that describes direct, indirect, fixed, variable, material, administrative, finance, and contingency costs; provides linkage to system product structure(s)**
- Scheduling** - a data model that identifies activities, dependencies, durations and milestones associated with products described in the WBS; includes WorkFlow Diagrams, Network Schedules, Gantt Charts and Resource Leveling. [ work with PLCS ]**

## AP233 Module Sets (cont.)

- Work Breakdown Structure** - a data model that represents the structure used to represent the pieces of work necessary to complete a project.  [ work with PLCS ]  **
- PDM** - a data model that extends the STEP PDM Schema and PDM Modules to electro-mechanical, system engineering, product life-cycle and other non-physical domains.  [ work with PLCS and PDM ]**
- Security** - a data model that describes project, organization, country and user defined security levels as well as user authentication and intellectual property.  [ work with PLCS and PDM ]  **

## AP233 Module Sets (cont.)

- Organizational Structure** - a data model that provides relationships, functional roles, skill qualification and documentation that defines an organizational structure.  [ work with PLCS ]**
- Validation and Verification Model** - a data model that describes the plan, infrastructure and status of validation and verification processes**
- Allocation Model** - a data model that describes structures necessary to allocate requirements, schedule, costs, risks and other functions associated with a body of work**
- AP Interface Models** - a data model that describes the interfaces between domain specific data models such as mechanical, electronic, structural analysis, thermal analysis, manufacturing, etc. [ work with other STEP AP groups ]**

## Team Members and Organization

- The STEP Systems Engineering Project is coordinated through the PDES Inc., a STEP consortium.  Standards organizations collaborating with the Project are INCOSE (International Council for Systems Engineering) and OMG (Object Management Group).

## Systems Engineering Project Participants

**NASA - ****J. U’Ren, H. Frisch, G. Siebes**
**Eurostep - ****P. Spiby, I. Bailey**
**BAE SYSTEMS – ****J. Johnson**
**NIST - ****P. Denno**
**Georgia Tech - ****R. Peak & Co.**
**Boeing – **** G. Smith, M. Keenan**
**MoD UK - ****M. Christensen, T. King**
**Lockheed Martin - ****S. Friedenthal**
**General Motors**** – M. Loeffler**
**Volvo - ****M. Lindeblad**
**United Technologies - ****R. Cohen**
**INCOSE - ****MDSD. Oliver, M. Dickerson**
**OMG - ****SE DSIG, S. Friedenthal**** **

## STEP in Spacecraft Development

- JAU 2002-10-25

- SLIDE_STEP-in-Spacecraft-Development-Ver12d.ppt

- How the family of STEP Data Standards
- can be applied to Spacecraft Development

- This slide provides high level information about how STEP and other standards can be applied to the engineering domains  that are part of the spacecraft development process.

- De-emphasized boxes indicate data models that are IN DEVELOPMENT.

## Tools used in testing AP233 Requirements Exchanges 

- Eurostep AP233  Demonstrator Tool
- Telelogics DOORS
- Rational RequisitePro
- EDS Slate
- Vitech CORE

- LKSoft STEP Book
- Expresso
- Eurostep SAS
- MS Word
- MS Excel
- Poseidon UML

## Tools used in testing AP233 Requirements Exchanges 

- Eurostep AP233  Demonstrator Tool
- Telelogics DOORS
- Rational RequisitePro
- EDS Slate
- Vitech CORE

- LKSoft STEP Book
- Expresso
- Eurostep SAS
- MS Word
- MS Excel
- Poseidon UML

## Current Approach of AP233 Work  

**Modularization**
**Avoids lengthy gestation of large AP efforts**
**Allows frequent, sequential deliveries**
**Provides on going evolutionary development environment**
**Active Development Team**
**Bi-weekly Telecons**
**Web-based repository to collect, secure and publish work-in-progress**
**Public website (in work)**
**Collaboration with existing Industry groups**
**INCOSE - International Council on Systems Engineering **
**OMG - Object Management Group  / SE Working Group**

## Status of Current Work

**Creating the modular AP233**
**to provide “hooks” into neighboring APs**
**reusing existing and creating new modules**
**Development of Semantic Data Dictionary**
**analysis of existing work**
**reuse and harmonize terminology as possible**
**Analysis of current STEP standards for:**
**Interfaces**
**Reuse**
**Integration**
**Harmonization**
**Develop preliminary 3 year project plan**
**draft plan published to Project Workspace (available on request)**

## Where do we go from here?

-  will continue collaboration between OMG SE DSIG and AP233 teams
-  extend areas of collaborative work through the PDES Inc consortium (LMC and NASA are current members)
-  next Aerospace PDE Workshop at NISTApril 7-10

## [ Backup Slides ]

## AP-233 and the STEP architecture

**Notes:**
This slide provides one view of the way AP-233 is seen to fit into the architecture of a comprehensive set of Application Protocols with STEP that cover full product data. This view was produced by the ESPRI organisation, not by SEDRES. It illustrates the cross-discipline view of AP233 and the Technical Data Packaging AP, AP-232, in contrast to the ‘specialist’ AP’s, such as AP203, tackling different ‘vertical’ domains, such as geometric design.

## SYSTEM ENGINEERING PROCESS(this example from IEEE1220)

**Sub-System specifications**

**Customer's**
**Requirements**

**Notes:**
We can take one of these contemporary processes, here IEEE 1220, which elaborates several of the activities that occur ‘within’ systems engineering. This indicates the interactions which occur between activities, which implies information exchange of design material taking place.

## The situation... Data Exchanges in context

**Notes:**
This slide indicates visually the interactions necessary:
across the full lifecycle;
across participating organisations.

## SE Process and SE Tools

**Notes:**
Typically any one project and/or organisation has decisions to make as to which of a number of tools are used to support these tasks, capturing design information and supporting the analysis and reporting tasks necessary to apply to that information.
Inevitably, these implies exchange between tools, since often different tools are used to support different activities.
Further even if a single tool can support all of these activities, there are exchanges necessary with the environments and stakeholders outside of this explicit context!

## From isolation to inter-working

**The Past**

**The Future**

- checks x,y,z

- views a,b,c

- checker/

- viewer

- tool A

- tool B

- tool A

- tool B

**2**

**3**

**4**

**1**

**The consequences:**
**Reduced benefits from each tool;**
**Costs migrating to new tools/versions;**
**Lack of an ‘integrated’ design dataset;**
**Compromised success of partnerships**

**The benefits:**
**Reduced costs to transfer & check data (1, 3);**
**Better achieve a coherent design (3, 4);**
**Facilitate Integrated Product Development (1, 3, 4);**
**Facilitate documentation/ design data management (2, 4)**

**Notes:**
A data exchange standard is a stepping stone to the ultimate objective of a design data centric (rather than design tool centric) design environment.

## Requirements for a system engineering exchange standard

- Requirements for a system engineering exchange standard

**Shall be compliant with SE processes**
**Support for primary, support & organisational processes**
**From requirement elicitation to V&V**
**Consistent with concepts of SEMP**
**Through life cycle support**
**Shall provide a tool independent representation**
**Shall be compatible with industrial organisation**
**Shall be implementable / adoptable by vendors**
**Lead to a consequential reduction in number / variety of design tool interfaces**

**Notes:**
This summarised the primary requirements for a systems engineering data exchange standard.
It has to be supportive of the systems engineering process, in other words it has to ‘do the job’.
It is essential that it is not seen as a tool-specific or even domain-specific standard.
It must be, in approach, architecture and implementation, a standard which is compatible with existing user organisations and their evolving infrastructure and tool integration policies.
It must be seen to implementable, both technically, and commercially.
And the bottom line is: the adoption of neutral standard-based exchange technology within an organisation must provide a net benefit to the support for the systems engineering activity, for instance, in reducing the number and variety of data exchange interfaces that would otherwise be required.

## Requirements: Process compatibility

**Notes:**
This pictorial view of lifecycle processes provides a contextual view for any systems engineering data exchange standard. Although the focus of such a standard may be rooted in a subset of such processes, for instance the primary process ‘development’, there are inevitably many interactions with the support and organisational processes with which systems engineering interacts.
For instance, one may categorise verification and validation activities as ‘support processes’, but these are fundamental to the systems engineering discipline.

## Requirements: Process - view points

**Requirement point of view**
**Functional structure point of view**
**Physical structure & allocation point of view**
**Configuration and traceability point of view**
**Project & data management point of view**

**Notes:**
Focussing on the primary systems engineering processes, this lists a number of data views that reflect SE processes and which must be accommodated. The following slides deal with each of these areas in more detail.

## Requirements: Process - Requirements

**Requirements, categories and structure**
**System context & operational modes**
**System environment description**
**Validation & verification information**
**Implementation verification**
**Requirement trade study information**
**Links to:**
**maturity, design phases, project control, project organisation, documentation support**

## Requirements: Process - Functionality

**Functional elements and child-parent hierarchy**
**Requirement allocation**
**Function inputs and function outputs**
**Data description**
**Behaviour description**
**possible modelling paradigms: state machines, time lines, structured text, logic tables, mathematical, analytical..**
**Links to:**
**maturity, design phases, project control, project organisation, documentation support**

## Requirements: Process - Physical structure

**Component description**
**Subsystem hierarchy definition**
**Data links / Physical interface definition**
**Information interface definition**
**Performance allocation**
**Function allocation**
**Support for validation, verification, traceability**
**Links to:**
**maturity, design phases, project control, project organisation, documentation support**

## Requirements: Process - Configuration and traceability

**Item identification and version control**
**Analysis iteration control with link to version**
**Traceability management (upward / backward)**
**Justification traceability**
**Security management**
**Link to full product management (consistency between real product and architectures)**
**Trade-off & Justification support**
**Exchange control**

## Requirements: Process - Project & data management

**Design process**
**Support for work breakdown structure**
**Support for a flexible process representation**
**Partner organisation, stakeholders**
**Design product packaging**
**Work allocation**

## Requirements: Tool independence

**Shall provide a tool independent representation**
**==>**
**Neutral format data exchanges**
**Neutral modelling paradigms**
**Flexible item representation and description**
**Extendibility**
**Long term design-data storage**
**Compatibility with several technology platforms**
**Upward compatibility with new enabling technologies (distributed environments, distributed repositories...)**
**Backward compatibility with simple exchange techniques**

**Notes:**
This slide elaborates on the requirement for tool independence in a systems engineering data exchange standard.
Neutral format data exchanges can be achieved by use of techniques such as ‘flat files’ and public standards such as SQL, SDAI and CORBA.
Neutral modelling paradigms underlie many design tool notations, for instance, finite state machine modelling or functional modelling.

## Requirements: Organisation

**Shall be compatible with industrial organisations**
**==>**
**Compatibility with industrial adopted technologies for data sharing & exchange**
**Support for organisation description and work allocation**
**User oriented / Usable**
**Supports both high / low data volumes; ‘deltas’**
**Supports data exchange management**
**Compatibility with other techniques used in industrial domains (CAD systems...)**
**Extensible - evolving processes / data types**

## Requirements: Vendor acceptance

**Shall be implementable / adoptable by vendors**
**==>**
**Shown to be implementable**
**Feasible to support (effort / cost / ROI)**
**Tool neutral / vendor independent**
**Based on mature data exchange technology**
**Widely supported by tools & consultancy**
**Widely supported by tool market users**

## Interface development process

- Exchange
- standard

- +

- +

- SE Tool
- STEP
- Interface

- Encoding
- formats

**Notes:**
Exchange standard (Application Protocol- AP)
Is a standard for exchanging information within an application domain.
Application Activity Model (AAM)
Is a process model that describes the context for an exchange in an application domain.
Application Reference Model (ARM)
Is an information model that describes the data involved in an exchange in terms understandable by practitioners in the application domain.
Reusable parts - Integrated Resources etc. (IR)
Are a set of common components that can be used across a number of Applications Protocols to facilitate interoperability between related APs.
Application Interpreted Model (AIM)
Is an information model that describes the data involved in an exchange of product data in terms of common components.
STEP provides a number of descriptive parts (meta-meta languages) for describing an AP (IDEF0, EXPRESS PART 11).
Encoding formats
Define the method for encoding the exchanged data.

## Example design encoding (Part 21)

- Handle
- Head Down
- Display

- pilot inputs

- system inputs

- display attributes

**Notes:**
A Part 21 encoding represents the design in a neutral format using th semantics of the Application Protocol (information model).
Each entity instance in the design maps to a record in the encoding.
Each record is identified as being of a particular type.
Each record has a reference number.
The attributes are encoded in the order they appear in the EXPRESS definition.
Missing attributes are encoded as ‘$’.
Attribute values are either actual values or references to other instances.

## AP233 Basic Philosophy & design principles

**Focussed on semantic level information**
**Graphics Unit of Functionality (UoF) is the exception**
**Aspects of data model driven from principles**
**Distinction between Instances and Definition**
**Concept to support ‘re-use’**
**Aspects driven by ease of model evolution**
**Relationship entities**
**Support of templates for textual descriptions**
**Model not tool-specific**

**Notes:**
Additional guidelines for the model development are listed here. Primarily the work was focussed at the semantic level of information that systems engineers work with, rather than focus on trying to exchange the information directly in the form with which they work work (which can be done via document exchange anyway).
Some of the concepts to be supported in the data model had a wide impact on the very structure of the data model. For instance, the notion of design re-use, where similar elements are repeated within the design in different contexts. An example would be a specification which contains two functions, control-left-engine, control-right-engine, but with the elaboration (definition) of these two functions identical. The aim was to support this concept explicitly, so concepts of instance and definition appear across several of the UoF’s.
A different category of impact on the structure of the data model comes from the STEP modelling style, which encourages relationship entities, rather than direct relationship constructs, to capture relationships. Arguably this is to make the data models more flexible to subsequent development.
Finally, the intention was that the data model was not intended to be tool specific, although many of the concepts supported will be recognisably related to many systems engineering tool notations.

## Requirement UoF (1)

**Related to Requirement elicitation phase**
**Defines several kind of requirements**
**Functional requirements**
**Constraints**
**Physical requirements**
**Operational requirements**
**Other categories can be added from**
**ECSS 10A**
**EIA632...**

**Notes:**
The Requirements unit of functionality covers textual statements about what a system must comply with, be they functional, architectural, operational aspects or system properties (safety or legislative requirements, performance, cost, etc.). 
The Capability/2 requirement model is limited in the sense it only accommodates textual requirements. Support for more advanced formats within the data model was consciously avoided to keep the information model size within reasonable bounds.

## Requirement UoF (2)

**Supports operational scenario definition**
**Supports Derived requirements & composition relationship**
**Defines the link between external entities and the system to be engineered**
**Externals / functional context **
**Concept of Traceability matrices support**
**To functional breakdown structure**
**To physical breakdown structure**

**Notes:**
Requirements may be grouped into arbitrary categories or requirement groups. There is also support for representing derived and alternate requirements and the establishment of traceability from requirements onto functional and behaviour elements of the model. The unit contains entities for representing the system under specification and its operational modes.

## Functional UoF (1)

**Not linked to a particular engineering methodology**
**SART style**
**RDD style**
**In-house...**

- Functions

- 1

- 2

- 3

- Data

- Behaviour

**What ?**

**When ?**

**How ?**

**Notes:**
The functional UoF is about capturing what a system is intended to do, in the sense of activities (functions) to be performed. There is a strong interrelationship between the Functional UoF (capturing functions and information) and the Behavioural UoF, which is more focussed on when activities occur and functions are to be performed.

## Functional UoF (2)

**Supports the functional breakdown structure**
**Functions, instance & definition**
**Hierarchical relationships**
**Flows**
**Flow groups**
**Stores**
**Data description**
**Data structure**
**Data types**
**Links to Behavioural model**
**Causal chain, Finite state machine, synchronous**

**Notes:**
The functional analysis unit of functionality contains entities for representing the functional architecture of a system. More specifically there is support for representing the functional context of the system, the functional hierarchy, functional interaction (flows), variables and data types.
There are tools supporting many variants of functional analysis on the market. The challenge in creating the functional architecture model was to create a framework supporting the basic features of functional modelling in a way acceptable to all tools. Care has been taken to create an unambiguous model for functional decomposition. The interface of each functional element is defined through entities called flow ports. The flow of a parameter to a function (in to or out from the function) is recorded in flow ports, thus providing a clear guidance on how the function shall be used. The flow port concept is not in use explicitly by all systems engineering tools but was found very useful for defining the interface of a function.

## Behaviour UoF

**Finite state machines (State chart style)**
**State, instance & definition**
**State hierarchies**
**Transition**
**Action on transition**
**Events**
**Control of functions**
**Causal chains for safety critical systems**
**Synchronous model (Clock driven behaviour)**

**Notes:**
The Behaviour area of the model extends the Functional Unit of Functionality to embrace detailed timing, sequencing and event-based behaviour of an emerging product. The Functional model of Capability/1 includes only the concept of functions, a functional hierarchy, and of interactions between functions. In practice, there are alternative modelling paradigms that are used to cover product behaviour. There are three paradigms included in Capability/2.
Firstly, there are finite state machine concepts, such as are embodied in tools such as Statemate. 
Secondly, there is a procedural or functional chain approach, such as that embodied in tools such as BAe CORE; 
Thirdly, there is a synchronous behavioural model, frequently encountered in safety-critical real-time embedded systems architectures, such as those found on aircraft.

## Physical UoF

**Component definition and breakdown structure**
**Product Breakdown Structure (PBS)**
**Bill of Materials (BOM)**
**Physical path description**
**Functional/physical mapping**
**	****_x0001__x0001_****Function****	****<=> ****	****Physical component**
**	****_x0001__x0001_****Flows****	****_x0001_<=> ****	****Physical links**

**Notes:**
This UoF supports the representation of the components that comprise a system. Furthermore, it supports the ability to allocate functions in the functional breakdown structure onto a component. A component has no specific links to a technology but rather represents a processing or functional unit. Therefore, it may represent a human being performing a task as well as a computer that would perform some complex calculation. The benefit of a physical model is that a systems engineer may assess several possible realisations of a system, initiate work load simulations and other activities to validate the correctness of the specification. In the same way that components host functions which are linked by flows, the latter are hosted by physical links. Again, these physical links are not technology dependent but are assigned performances so that overall system performance simulations can be initiated. In terms of system engineering activities this is tightly linked to trade-off studies and load balance between components and physical links.

## Graphics UoF

**Objective: **
**ensure (where applicable) that designs on receiving tool can bear ‘similarity’ in layout to original**
**Visual Elements**
**Nodes, links that appear on SE diagrams**
**Association to semantic elements**
**Graphics points (nodes, links, link path) for diagram layout**
**Is this the most appropriate approach?**

**Notes:**
The Capabilty/2 data model includes support for visual presentation of designs (the UoF Graphics). This component enables the graphical representation that a designer has used in a source tool, such as a data flow diagram or a state transition diagram, to be reproduced on the destination tool. Although this component does not, of itself, communicate any semantic aspects of a design, the communication of diagram layout information appears to be crucial aspect when one inspects how designers may subsequently communicate about a design, especially when they are working in a distributed design situation.

## System configuration management UoF (1)

**Configuration Management Item & Item Id**
**Traceability matrices support**
**From requirements through to physical components**
**Documentation support (‘Package’)**
**Support for version control**
**release / approval**
**versions **
**variants**
**workspace revision**

**Notes:**
The System Configuration Management UoF in Capability/2 include concepts associated with configuration management or (more correctly) product data management. The model distinguishes between design model items and process items. Design model items represent the information that forms the emerging design (such as requirements information or functional hierarchies). Process items capture information about, or related to, the design process. The UoF supports traceability from requirements to elements of the emerging design in later stages of the design process. It enables multiple elements to be grouped into ‘packages’. The CM UoF involves issues such as: item identification, authorship, versioning, and item maturity (life cycle).

## System configuration management UoF (2)

**Support for justification and maturity indices**
**Relationships to process**
**work breakdown, activities & products**
**Support for industrial schema**
***“******Who does what and where”***
**Project**
**Company Id**
**Person Id**
**Convergence with STEP Product Data Mgmt (PDM) Schema**

**Notes:**
The process areas of the System Configuration Management UoF enables design items to be related to the activities within that process and to work packages. 

The model has been developed to align with the emerging common PDM schema being developed concurrently with the STEP community, in so far as has been possible. Product data management is a challenging area, in part because it is rich in concepts and interrelationships. Also in practice all design tools cover this scope to a greater or lesser degree, and design tools are increasingly used in conjunction with dedicated products data management tools, such as SQL’s PCMS or Dassault Systeme’s Product Manager.

## STEP Interface usage w.r.t SE Tools

**Tool API**

**Raw Data**

**SE Tool**

**STEP Tool**

- Information models

- SE Tool
- Data Format

- Neutral
- Data Format

- Semantic mapping

**Part 21**

**“****SDAI”**
**Part 22**

**Notes:**
A STEP interface bridges the gap between design tool data in a design tool proprietary format and the exchanged data held in a neutral format.
This is not simply a conversion of data between two different formats. There is a semantic mapping as well between the design tool and the Application Protocol which reflects the way a particular design tool is used in the Systems Engineering process, eg. If a data flow notation is used to represent a functional hierarchy then a particular data flow instance in the design tool may map to different entities in the Application Protocol dependent on its relationship to other data flow instances in the design:
the top level data flow will map to the system functional context
intermediate level data flows will map to composite function definitions
bottom level data flows will map to leaf function definitions.
The interface needs to be able to access the data in both the design tool and the exchange files, and implement a semantic mapping between the two.
Interface development may be supported by a STEP tool using information models, data formats and semantic mapping information as inputs

## Test & Evaluation: ‘the bottom line’

**Actual measurements of limited exchanges capture how time spent**
**Simple analysis indicates projected times**
**Note several activities currently due to prototype technology:**
**Produce Part21 file..**
**Manage & transfer..**
**Prepare for import**
**..are likely to go to zero in industrial implementation**

**Notes:**
The above diagram shows a saving in time using the SEDRES concept over an equivalent manual process.
The prototype nature of the interfaces introduced an overhead in the exchange process that would be reduced in production versions.
Some of the exchange time requires zero effort from the user.
Most of the import time involves the user becoming familiar with the design after it has been imported, which is a value adding activity.
The transfers were performed with designs containing about five diagrams plus associated data dictionary entries (process, data and state descriptions).
The projected values were interpreted by observers not involved in the interface developments. We feel that in practice most of these values would be lower still.