Abstract. INCOSE and the Object Management Group (OMG) are collaborating on an initiative to extend the Unified Modeling Language (UML) to provide a general-purpose systems modeling language to support analysis, specification, design, and verification of complex systems. This language will be a key enabler for transitioning the practice of systems engineering from a document-centric to a model-centric approach. Many different applications of UML to systems engineering have been demonstrated and published, and are in active use by various groups, but a standardized extension of UML for systems engineering is not currently available. This paper provides the background, motivation, and approach of this critical initiative to develop a standardized extension of UML for systems engineering, and highlights some of the early results to establish the requirements for the modeling language. Additional information can be found on the OMG Systems Engineering Domain Special Interest Group (SE DSIG) web site at http://syseng.omg.org.

Background

Role of Systems Engineering. Systems engineering is an interdisciplinary application of the systems engineering process. Its primary objective is to ensure that the system being developed or modified represents a cost-effective solution that satisfies the needs of the customer, end users, and other stakeholders. The systems engineering process involves analyzing stakeholder needs, specifying the system requirements to address the needs, defining, evaluating, and selecting among alternative system architectures to achieve an optimum allocation of system requirements to the system components, supporting the component development and integration, verifying that the system satisfies its requirements, and validating that the system satisfies the stakeholder needs. Of particular importance is for the systems engineering process to ensure that the broad range of requirements related to performance, reliability, safety, security, producibility, maintainability, cost, and other life cycle considerations are properly addressed. In addition, the systems engineering process includes a disciplined management approach to plan, assess, and control the technical effort to ensure it satisfies the overall project objectives and constraints.

Current Practice of Systems Engineering. The current practice of systems engineering has evolved over the last half century, and resulted in the successful implementation of many complex systems. Clearly, the manned space project in the 1960’s, resulting in a man being safely transported to the moon and back, can be viewed as a significant early application of systems engineering. Since then, the application of systems engineering has been applied to the development of many complex systems for the US military, which has been well documented in various Department of Defense (DoD) manuals and standards, as well as many texts on systems engineering. Increasingly, the practice of systems engineering is being applied to commercial systems, such as telecommunications, health care, and other areas, as evidenced by the systems engineering applications working groups within INCOSE, and the adoption of several commercial standards for systems engineering.

The practice of systems engineering has traditionally involved extensive documentation to capture the primary work products of the systems engineering process. Typical systems engineering documentation includes specifications, interface control documents, system design documents, trade studies and analysis reports, and verification plans, procedures, and reports. The systems engineer has used a variety of modeling techniques to support analysis of the system requirements and design, including functional flow block diagrams, schematic block diagrams, N2 charts, IDEF diagrams, behavior diagrams, and others (Long 2002).

Improving the Practice of Systems Engineering. There have been several initiatives under way to improve the practice of systems engineering over the last decade. These include the introduction of several process standards, including EIA-632, IEEE-1220, and ISO/IEC 15288. The ISO/IEC 15288 System Life Cycle Processes are shown in Table 1, and encompass agreement, enterprise, project and technical process groups. In addition to the process standards, process maturity models have been introduced to assess the maturity of an organization’s implementation of their processes. The Capability Maturity Model Integrated (CMMI®) has been introduced to assess the integration of systems and software practices into an organization. These process standards and complementary assessment models are providing a significant impetus to improve the practice of systems engineering.

Agreement processes	Enterprise processes	Project processes	Technical Processes
Acquisition	Enterprise Environment Management	Project Planning	Stakeholder Requirements Definition
Supply	Investment Management	Project Assessment	Requirements Analysis
	System Life Cycle Processes Management	Project Control	Architectural Design
	Resource Management	Decision-making	Implementation
	Quality Management	Risk Management	Integration
		Configuration Management	Verification
		Information Management	Transition
			Validation
			Operation
			Maintenance
			Disposal

Table 1. ISO/IEC 15288 Processes

Over the last few years, there has been growing interest in developing data interchange standards for systems engineering to support systems engineering tool interoperability. ISO AP-233 has evolved from the European-funded Systems Engineering Data Representation and Exchange Standardization (SEDRES) project. AP-233 is part of the ISO STEP 10303 standard effort, which provides standardized models and infrastructure for the exchange of product model data. The result of the AP-233 effort will be an “Application Protocol” for Systems Engineering, which defines a neutral format for exchange of systems engineering data among tools.

Need for a Standard System Modeling Language. One of the critical areas to achieve significant improvement in systems engineering, which has been recognized by INCOSE and across industry, is the need to transition the practice of systems engineering from a document-centric approach to a model-centric approach. This has been the focus for the INCOSE Model Driven System Design (MDSD) Working Group, as well as many other initiatives across industry.

As mentioned previously, system engineers have successfully used many modeling techniques and documentation approaches. However, the systems engineering community still lacks a standard modeling language that is widely accepted and practiced. Other engineering disciplines, including electrical, mechanical, and more recently software, have standardized the specific modeling languages and notations suited to their disciplines. Electrical engineers long ago recognized the need to standardize the representation for resistors, capacitors, inductors, transistors, logic gates, etc. The lack of a robust “standard” modeling language for systems engineering limits the ability to support consistent and effective communication of system requirements and designs among systems engineers and other disciplines. The lack of a standard language also results in potentially higher costs to organizations that must support different languages and tools. The quality, productivity and effectiveness of the systems engineering process will be significantly enhanced by adopting and applying a standard modeling language.

Modeling Language Evaluation Criteria. A system modeling language is intended to support analysis, specification, design, and verification of complex systems by:

1) Capturing the systems information in an efficient and precise manner that enables it to be integrated and reused in a broader context

2) Analyzing and evaluating the system being specified, to identify and resolve system requirements and design issues, and to support trade-offs

3) Communicating systems information correctly and consistently among various stakeholders and participants

Specific evaluation criteria for the systems modeling language should include:

1) Ease of use. The language should be able to be used and interpreted by a broad range of stakeholders.

2) Unambiguous. The language should be based on well-defined semantics with unambiguous notation, resulting in a consistent set of model views which adhere to specified well-formedness rules.

3) Precise. The language should specify the semantics, which can be translated into a formal mathematical based representation (e.g. object constraint language or other constraint language). This capability should facilitate execution of the specification and design models at each level of the system hierarchy, to validate the requirements and verify that the design model satisfies the requirements.

4) Complete. The language should address the breadth of systems modeling concerns to support system analysis, specification, design, and verification.

5) Scalable. The language should provide support for modeling abstractions, elaborations, and refinements (e.g. generalization / specialization, decomposition, collection, multiple views, etc.) to provide scalable solutions for modeling complex systems.

6) Adaptable to different domains. The language should provide the capability to extend the semantics and notation of model elements to support specific domains (e.g., aerospace, telecom, automotive).

7) Evolvable. The language should be designed for change, and support backward compatibility with previous versions.

8) Model and diagram interchange. The language should support mapping to the AP-233 neutral data exchange format (technical scope only) to exchange semantic information between tools. It is expected that both AP-233 and the OMG XMI format will provide mechanisms to exchange data, which may be represented in other systems engineering modeling languages, such as behavior diagrams, IDEF0, etc, as well as requirements management tools, and other analysis and design models. In addition to semantic interchange, the language should be capable of diagram interchange to facilitate the exchange of models from one tool to another including the notational and diagram layout information.

9) Process and method independent. The language should be capable of supporting industry standard systems engineering technical processes, including EIA 632 and ISO/IEC 15288, and not constrain the choice of a specific process or method.

Adopting UML as a Systems Modeling Language

Motivation to Extend UML to Model Systems. The Unified Modeling Language (UML) is a graphical language for modeling software systems, which was adopted as V1.1 by the Object Management Group (OMG) in 1997. Since then, UML has become a de-facto standard among the software community. The language has continued to evolve to V1.41 as of the end of 2002, and has been undergoing a major revision to UML V2.0, which is planned for adoption in 2003. During this period, UML has begun to gain a level of usage and acceptance among the systems engineering community. A customization of UML as a standard systems modeling language offers the following benefits.

1) UML is a robust language, with built-in extension mechanisms, capable of addressing many of the evaluation criteria described above for the general-purpose systems modeling language.

2) A UML extension for SE would facilitate integration with software UML models, which continues to represent an increasing portion of the overall modeling effort on a project.

3) UML and its extensions are supported by the OMG, which includes a defined technology adoption process and broad user representation, to assist in further evolution of the language.

4) UML is supported by an extensive infrastructure of tool vendors and training that the systems engineering community can leverage.

As a result, INCOSE has selected the path of extending UML to provide a general-purpose systems modeling language for analyzing, specifying, designing, and verifying complex systems.

UML Highlights. The increasing complexity of software has motivated development of languages for describing software systems clearly and unambiguously. UML is intended to provide a well-defined set of semantics (meaning) and an associated notation, to provide a comprehensive, unambiguous, and precise language for specifying software systems. In addition, UML is supported by the XMI standard, which translates UML into an XML format for data exchange. This is intended to facilitate model interchange among UML tool vendors.

Although UML was created as a software modeling language, its success and its flexibility now motivate extension to other disciplines. UML includes extension mechanisms called stereotypes, tagged values, and constraints, which enable the base modeling elements to be extended to meet requirements of other modeling domains. These extensions, and an applicable subset of UML, can form the basis for a UML Profile for Systems Engineering, to provide the general-purpose system modeling language.

UML V1.5 includes a comprehensive set of model elements (e.g. class, package, association, etc.) which provide the core constructs for representing the UML diagrams to model the structure and behavior of software systems. The nine UML diagram types are listed in Table 2 and summarized briefly below.

UML V1.5 Diagram Type

Activity diagram

Class diagram

Collaboration diagram

Component diagram

Deployment diagram

Object diagram

Sequence diagram

Statechart diagram

Use case diagram

Table 2. UML V1.5 Diagram Types

A use-case diagram provides a high-level description of the software system functionality, including a representation of the actors, which are external to the system, and the use cases, which correspond to the basic functionality the system and actors support. The activity diagram, sequence diagram, collaboration diagram, and statechart diagram provide representations of the behavior of the software system. An activity diagram represents the flow of control between activities. A sequence diagram and collaboration diagram represent the flow of control among collaborating objects, in terms of messages being passed between them. A statechart diagram describes the transitions of an object from one state to another in response to events, and the actions which occur within a state.

The structure of software systems is represented in UML by class diagrams, object diagrams, component diagrams, and deployment diagrams. A class diagram represents the software system in terms of its classes and their associations, and also includes the concept of generalization/specialization to capture common and unique class features (operations and attributes). The object diagram is similar to a class diagram, but includes class instances (objects) and their structural relationships. The component diagram describes how classes can be partitioned among software components, and the dependencies between components. The deployment diagram represents how software components are deployed to processing nodes for execution, and the interconnection between nodes.

These diagrams are readily interpretable by a knowledgeable user, and are intended to be sufficiently unambiguous and precise to be translated directly into code. However, the language requires further enhancements to truly achieve this level of precision “out of the box.”

As mentioned previously, a major revision to UML V2.0 is planned for 2003. This version is intended to address many of the shortcomings that have been identified in the language, and improve its usability and applicability.

INCOSE/OMG Initiative to Extend UML to Systems

INCOSE/OMG Initiative. At the January 2001 International Workshop, the recommendation was made during the Model Driven System Design (MDSD) Working Group meeting to pursue UML as a standard modeling language for systems engineering. INCOSE and the OMG signed a Memorandum of Understanding in July 2001, and chartered the OMG Systems Engineering Domain Special Interest Group (SE DSIG). The SE DSIG kick-off meeting was held September 13, 2001, with the focus on extending UML to support systems engineering.to achieve the following goals:

· Provide a standard SE modeling language to specify, design, and verify complex systems

· Facilitate integration of systems, software, and other engineering disciplines

· Promote rigor in the transfer of information between disciplines and tools

The SE DSIG effort is being coordinated with the AP-233 effort, to help ensure consistency between the UML extension for systems engineering and the AP-233 data interchange standard for systems engineering.

SE DSIG Approach. The SE DSIG is following the approach generally used by the OMG to adopt a technology or UML specification. This approach involves developing the requirements, which are then issued to industry as a Request for Proposal (RFP). Typically, one or more cross- industry teams collaborate to provide a response to the RFP. The OMG then evaluates the RFP’s, and selects the proposal for adoption that best satisfies the RFP requirements and has the broadest industry support.

The SE DSIG developed the requirements for the systems engineering modeling language. The draft requirements were provided as early inputs to the UML V2.0 submission teams, so they could identify potential refinements to their proposals to address systems engineering needs. The requirements were further refined and. incorporated into a UML for Systems Engineering RFP, which was issued at the March 2003 OMG meeting. The specific tasks used to establish the requirements are summarized in the following sections.

UML for SE RFI Responder

Artisan

BAE Systems (CNI Division)

Georgia Tech

Holistic Systems Engineering

I-Logix

INCOSE OOSEM Working Group

Lockheed Martin Corporation

Mitre

Project Technology

Rational Software

Systems Engineering Consulting

Tofs AB

Volvo Car Corporation

Table 3. Responses to the UML for SE Request for Information (RFI)

UML for SE Request For Information (RFI). The SE DSIG issued a UML for SE RFI through the OMG, and received 13 responses from a broad spectrum of end users, tool vendors, and researchers, as shown in Table 3. The RFI included several questions related to how UML is being applied to systems engineering, its benefits, limitations, and potential solutions. The information provided a valuable source of requirements, issues, and potential solutions to support development of the UML for SE requirements and follow-on solutions. These responses can be found from the RFI link on the SE DSIG web site. The responses indicated the following:

· The application of UML to systems engineering is increasing across a broad spectrum of systems engineering applications (aerospace, information systems, telecommunications, automotive), although it is still in a fairly early stage. The application of use cases and scenarios, including activity diagrams, sequence diagrams, collaboration diagrams, and state charts, are being used to analyze and specify system behavioral requirements. The use of class diagrams, component diagrams, and deployment diagrams are being used to describe system structure. In addition, UML modeling tools are being integrated with requirements management tools to manage the requirements traceability.

· The use of UML is providing generally positive results, including improved communications among systems, software, and test engineers, project management and the customer, and enhanced understanding and precision for the system requirements, design, and test.

· Several limitations with UML V1.x were identified, which need to be addressed to provide comprehensive support for systems engineering. These include lack of constructs and models to support hierarchical behavior, hardware specification, physical interfaces, performance attributes, specialty engineering concerns, continuous systems, and others.

· Many of the limitations were addressed by straightforward work-arounds, and others by novel approaches. These include the application of constraints to continuous time properties and the use of ports to define physical interfaces (Axelsson 2002); approaches for hierarchical modeling (Lykins, et al 2000, Moore 2002); the concept of locality to support a more generalized node concept for distributed systems (Cantor 2002); the use of object constraint graphs to define the parametric relationships and associated equations to integrate geometric design models with analytic models, such as thermal analysis (Peak 2002); and many other interesting and promising applications of UML. These approaches, along with several other innovative approaches for addressing the limitations in UML for systems engineering, are included in the references below.

· There is broad interest among the tool vendor community to provide a system UML modeling capability, as evidenced by the tool vendors who responded to the RFI, and/or are participating directly in the SE DSIG. Many of these vendors are currently developing solutions to support systems engineering, and have indicated they will implement UML for SE when it is adopted.

SE Concept Model. The Systems Engineering (SE) Concept Model is a joint effort between the SE DSIG, AP-233 and the INCOSE MDSD. This model is a high-level information model (schema), which is intended to define the entities and relationships for describing system behavior, structure, properties, requirements, and verification. It includes a UML class diagram to represent the schema, and a semantic dictionary to define the terms. The complete model is available from the SE DSIG and AP-233 websites.

The SE Concept Model is a primary input to the UML for SE requirements and to the AP-233 model for data interchange. As such, the SE Concept Model is a key mechanism to synchronize the AP-233 and SE DSIG efforts. David Oliver has led the joint effort between AP-233 and the SE DSIG, and has held a series of joint reviews to identify and resolve issues.

UML for SE Evaluation & Prototyping. The UML for SE Evaluation & Prototyping effort was established to evaluate alternative approaches for expressing the fundamental systems engineering concepts in UML, and to help identify some of the common issues and proposed solutions. This team, led by Rick Steiner, focused on creating a matrix that identified alternative approaches that different users have applied to represent concepts from the SE concept model. It was apparent from the evaluation that many of the systems engineering concepts were being addressed in different ways, and several of the concepts were not addressed at all. This evaluation provided an additional input to the overall requirements analysis and solutions for UML for SE.

UML for SE Requirements Analysis. The UML for SE Requirements Analysis (V0.4 dated November 12, 2002) summarized and refined critical inputs from the UML for SE RFI responses, the SE Concept Model, and the UML for SE Evaluation & Prototyping, as well as other inputs, to document the systems engineering concepts, the perceived limitations associated with representing those concepts in UML, and potential solutions. This has provided a consolidated input for the requirements for UML for SE.

The requirements for UML for SE include various constructs to represent the behavior, structure, and properties of systems. In addition, it includes the requirements to represent fundamental modeling paradigms needed for systems engineering, such as hierarchical behavior and structure, parametric relationships to support analytic models, etc. These are summarized in the UML for SE RFP section below.

The perceived limitations, which reflect perceived limitations with UML V1.x, are summarized in Table 4. These include limitations in representing continuous time properties, hardware components, physical interfaces, input/output flow, performance attributes, parametric relationships, and others.

Perceived Limitations of UML V1.x

Continuous time behavior

Decision tree

Hierarchical modeling of behavior and structure

Input/output flow (i.e data, mass, energy)

Parametric models and integration with other analysis models (i.e. performance, reliability, safety, ..)

Performance and physical characteristics (including probabilities)

Physical interfaces and connections

Problem definition and causal analysis

Requirements constructs

System, subsystem, and component representations

Terminology harmonization

Verification and validation models and constructs

Table 4. Perceived systems engineering limitations of UML V1.x

As previously mentioned, multiple solutions have already been developed for addressing many of these issues that will provide excellent inputs to the implementers of UML for SE. The UML for SE Requirements Analysis includes references to several of these sources, including the RFI responses, but this list is by no means complete. There have been an increasing number of publications over the last few years in the INCOSE journal and papers, as well as in texts, that describe various approaches to UML for SE. However, the UML for SE Requirements Analysis does provide a fairly broad sampling of these approaches, and can be used to get a good understanding of the breadth of applications.

SE DSIG Collaboration with UML 2.0 Submitters. UML V2.0 represents a significant revision to V1.4, and is intended to address many of its limitations, including several which may enhance support for systems engineering. The UML V2.0 RFP includes an infrastructure RFP to provide the underlying UML constructs, a superstructure RFP to provide the basic diagrams, a diagram interchange RFP, and an RFP to enhance the Object Constraint Language (OCL). Several submissions teams responded to one or more of the RFP’s. The OMG is currently evaluating the submissions, with the expectation to adopt a UML V2.0 specification in 2003.

The UML V2.0 submitters were refining their proposals at the same time that the SE DSIG was developing the requirements for UML for SE. This enabled the opportunity for the SE DSIG to provide the evolving requirements as inputs to each of the submission teams. In addition, several workshops and other meetings were held with members of the U2 Partners (U2P) submission team, coordinated by Cris Kobryn. This enabled the team to assess the extent to which their proposals addressed the UML for SE requirements. The SE DSIG inputs to the U2 Partners may be found off the Collaboration link of the SE DSIG web site.

UML for Systems Engineering (SE) Request For Proposal (RFP). The UML for SE RFP specifies the requirements for the systems modeling language, and is issued to industry by the OMG for their responses. The requirements were derived from the SE DSIG activities described previously, and were initially reviewed by SE DSIG and AP-233 team members at the Washington OMG meeting in November, 2002. The requirements were updated and incorporated into the draft RFP, which was reviewed at the OMG meeting in January 2003 and the INCOSE International Workshop in February 2003. The RFP was issued at the OMG meeting in Orlando, Florida on March 28, 2003, and is available on the UML for SE RFP page on the SE DSIG web site.

The mandatory requirements for the SE modeling language are included in Section 6.5 of the UML for SE RFP. The requirements categories in this section are generally consistent with the primary groupings in the SE Concept Model, and include requirements for modeling structure, behavior, properties, requirements, verification and validation, and a general category for other types of modeling requirements. In section 6.6 of the RFP, there is an additional set of optional requirements, which may be addressed in follow-on submissions. The glossary in Appendix A.2 of the RFP includes a core set of terms that are used in the RFP. In addition, a more comprehensive glossary of terms and definitions is provided on the UML for SE RFP web page, along with other RFP references.

Table 5 provides a high-level summary of the requirements in the RFP. The reader should refer to the RFP itself for the precise and detailed specification of these requirements.

Modeling Structure:

· UML for SE shall provide the capability to model the decomposition of a system into its component parts, which may include hardware, software, personnel, etc.

· UML for SE shall provide the capability to model the environment of a system.

· UML for SE shall provide the capability to model the interconnection of a system with the elements in its environment, as well as among its components.

· UML for SE shall provide the capability to model the deployment of components to nodes.

Modeling Behavior:

· UML for SE shall provide the capability to model functional transformations of inputs to outputs, and stores.

· UML for SE shall provide the capability to model the activation and deactivation of functions, including control operators, such as joins, merge, fork, etc, and triggering events and conditions.

· UML for SE shall provide the capability to model both function-based and state-based behaviors.

· UML for SE shall provide the capability to model the allocation of behavior to systems and components.

Modeling Properties:

· UML for SE shall provide the capability to model different types of properties (quantifiable characteristics), and associate them with a system, input/ouput, or function.

· UML for SE shall provide the capability to assign values, units of measure, and probability distributions to properties.

· UML for SE shall provide the capability to model time as a global property, which can be accessed by other properties.

· UML for SE shall provide the capability to model parametric relationships (i.e. mathematical or logical equations) between properties in support of various engineering analysis models.

Modeling Requirements:

· UML for SE shall provide the capability to model the various types of requirements, including functional, interface, performance, etc.

· UML for SE shall provide the capability to assign attributes to requirements (i.e. criticality, TBD, risk, verification status).

· UML for SE shall provide the capability to model requirements relationships, including traceability among requirements, and between requirements and implementation.

· UML for SE shall provide the capability to model problems, and relate problems to systems, components, etc. and relate one problem to another to support causal analysis.

Modeling Verification:

· UML for SE shall provide the capability to model test cases.

· UML for SE shall provide the capability to model verification results and the comparison between the requirements and the results.

· UML for SE shall provide the capability to model verification procedures and the verification system that implement the procedures.

Other Modeling Requirements:

· UML for SE shall provide the capability to model general relationships among model elements, including decomposition, dependencies, generalization/specialization, …

· UML for SE shall provide the capability to model various views of a system, representing a subset of model elements.

· UML for SE shall provide support for standard UML diagrams with the applicable UML for SE extensions, and other diagrams to support the requirements (i.e. context, parametric models).

Optional Requirements: