UML for Systems Engineering RFP

DRAFT November 12, 2002

Object Management Group

First Needham Place

250 First Avenue, Suite 201

Needham, MA 02494

Telephone: +1-781-444-0404

Facsimile: +1-781-444-0320

UMLTM Profile for Systems Engineering RFP
Request For Proposal

OMG Document: ad/2003-03-xx

November 11, 2002

THIS IS A ROUGH DRAFT TO SERVE AS A STARTING POINT ONLY,

AND IS SUBJECT TO MAJOR REVISION
Letters of Intent due: March 21, 2003

Submissions due: October 27, 2003

Objective of this RFP

This Request for Proposal solicits submissions that specify a UML™ Profile for Systems Engineering. The application of UML to systems engineering is intended to support modeling of a broad range of systems, which may include hardware, software, data, personnel, procedures, and facilities.

This application of UML should assist participants in the specification, design, and verification of complex systems to 1) increase understanding of the system being designed, including the ability to identify issues and analyze them for decision-making, 2) communicate systems information consistently and unambigiously with stakeholders, and 3) capture the systems information in an efficient and precise manner in ways that can be integrated and reused in a wider context.

The specification developed in response to this RFP is expected to achieve all of the following:

•Ability to represent all elements of a system design that may need to be communicated among developers and stakeholders throughout the process of specifying, designing, and verifying the system.

•Ability to model a broad range of system domains (e.g., aerospace, telecom, automotive).

•Ability to extend the modeling constructs and their syntax to represent unique entities and relationships applicable to different domains and design representations.

•Integration with other modeling languages including ability to support model interchange standards with other modeling representations already in use for systems engineering

•Compliance with the UML standard (currently UML 1.4.1 but expected to be UML 2.0 by the time of responses to this RFP).

•Independence from specific process or method used to develop a design through its lifecycle.

A standard for representing systems engineering designs using UML will provide designers with the ability to develop and exchange specifications using standardized notations and representations that can be understood in precise and consistent ways. This will increase communication between all the different participants in systems design and between different tools that support the design process, from requirements management to modeling and analysis to simulation, prototyping, and deployment. Such a standard can enable more flexible selection of tools that offer specialized capabilities to meet specific needs, while still allowing integration with other tools. Basing systems engineering representations on UML will also extend the user skills, tools, and knowledge of UML that already exists in the software development community to related needs of systems engineering.

For further details see Chapter 6 of this document.

Sections 1-5 are OMG boilerplate and are omitted from this draft.

6.0Specific Requirements on Proposals

This section provides the information specific to this RFP.

6.1Problem Statement

(Background motivation and statement of the problem still needs to be assembled and integrated from various sources. Here are some fragments of existing text that provide at least a starting point.)

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.

Motivation for a Standard System Modeling Language. As mentioned previously, Tthere are several modeling languages that have been successfully used by systems engineers. However, the systems engineering community still lacks a standard language that is broadly practiced. Other engineering disciplines, including electrical, mechanical, and more recently software, have standardized on a modeling language, Electrical engineers long ago recognized the need to standardize on the representation for resistors, capacitors, inductors, transistors, logic gates, etc. The lack of a standard modeling language for systems engineering limits our ability to support consistent and effective communication of system requirements and designs amongst systems engineers, and other disciplines. The lack of a standard modeling language also results in potentially higher costs to organizations to support different tools and training. A standard modeling language, to support model centric design, will significantly enhance systems quality and improve productivity.

UML has become a standard modeling language amongst the software community, and is believed to be sufficiently robust to support extensions to address the needs of systems engineering. In addition, UML has an extensive supporting infrastructure through OMG, which includes broad industry representation, and a defined process and infrastructure for extending the modeling language. A standard modeling language for systems engineering to specify, design, and verify complex systems, is intended to enhance systems quality, improve the ability to exchange systems engineering information amongst tools, and help bridge the semantic gap between systems, software, and other engineering disciplines.

Include the outline of systems engineering concepts to be included with an example such as airplane to be provided in each category. Two charts from Sandy’s presentation “Extending UML from Software to Systems” may be usable for material: 1) the diagram with an airplane at the center and multiple models and diagrams around the periphery, behavior and structure models above and below and safety model and performance model as examples to left and right, and 2) airplane example slide with specific concepts listed.

The text of this second slide consists of:

Systems Specification & Design Considerations – Airplane Example

  • Behavior – taxi, takeoff, fly, land
  • Structure - wing, engine, fuselage, avionics, control
  • Physical characteristics - weight, wing span, length
  • Performance characteristics - speed, maneuver, range, payload
  • Non-functional - safety, security, reliability, cost
  • Environment - altitude, temperature, turbulence
  • External I/F - control tower, pilot, maintenance equipment
  • Life cycle - manufacturing, support, training, disposal

6.2Scope of Proposals Sought

(This is initial draft text to clarify the scope of this request, to explain at least some of the basic rules for the scope that is included and to specifically exclude potential areas of wider interest that are not part of this request.)

Specific requirements for the requested UML Profile are detailed in sections 6.5, 6.6, and 6.7. This section explains the rationale behind the requirements that have been included in this scope, and clarifies other potential issues or modeling needs that have been deliberately excluded from the scope of the requested profile.

This requested profile is to address the technical aspects of modeling systems, not the management aspects of the systems engineering process (e.g. planning, risk management, configuration management, etc). The modeling views and notations of UML are to provide a basis for representing a system under design at multiple levels of detail and from multiple perspectives throughout its evolution and refinement, from initial requirements to conceptual through design andto final verification and deployment.

The requirements for representing a system under design are organized in Section 6.3 under the following system modeling categories:

  1. Structure
  2. Behavior
  3. Property
  4. Requirement
  5. Verification & Validation
  6. Other

The requested scope is for a general-purpose systems modeling language. This general-purpose language will include features that allow it to be extended and customized to support or integrate with more domain-specific languages and notations. The unique extensions required for any particular domain, however, are not within the requested scope. Examples of such extensions may be provided, but should be clearly identified as example applications of the general-purpose language and not part of the specification of the language itself.

Many specialized analytic models, such as for safety, reliability, performance, and geometry, are used within systems engineering. The UML-based modeling framework may provide a context in which such models and their supporting notations can be integrated with each other and with an overall design. The requirements identify all the underlying modeling elements, which the general-purpose modeling language must support to enable integration of related analytical tools.

The modeling requirements have been selected according to the needs for representing the actual system under design, not its mapping to some generic implementation platform. Such platform-dependent mappings are key features of the OMG Model-Driven Architecture for software, but the meaning of such platform-specific mappings is not as clear for systems in general. Enabling a model-driven approach for systems design is a core goal of the requested modeling language, but the models to be supported are focused on the design itself rather than some generic mapping to some target implementation platform. Implementation aspects of the system under design may be directly included in the system design to the extent that the requested modeling elements are sufficient to express them, but additional elements that would be needed to support generic forms of mapping from a single system design to multiple implementation targets are not part of this request. When software components are themselves part of the system design, there is nothing to preclude use of other OMG specifications to accomplish a platform-specific mapping, but this request does not include any requirements specifically selected to support such mapping.

6.3Relationship to Existing OMG Specifications

OMG context and scope.The SE DSIG effort is part of OMG’s broader effort to evolve UML to address both general and domain specific requirements, such as manufacturing, telecommunications, and healthcare. (Add more on MDA and relation to OMG’s wider directions.)

Proposals are expected to be consistent with, extend or, possibly, override the following specifications. In each case, the most recent version is applicable unless the most recent version was adopted less than six months before the final submission to this specification.

  • Unified Modeling Language (UML) Specification (formal/01-09-67) – The UML Profile for SE should incorporate a subset of UML and extend it only as necessary, using techniques of extension defined by UML itself as far as possible.
  • UML Profile for Schedulability, Performance, and Time (ptc/2002-03-02) – The UML Profile for Systems Engineering may be able to make direct use of many elements of this specification as well as basic techniques and approaches.
  • UML Profile for EDOC (ptc/02-02-05) – The UML Profile for Enterprise Distributed Computing includes elements to model business processes, collaborations, and flows that may overlap with modeling needs for systems in general.

The following specifications form the core of the UML 2.0 submission process currently in progress. According to current roadmaps, all these specifications may be in a final adoption process by time of submission to this RFP. To the degree that schedules permit, a UML Profile for Systems Engineering should be based to the extent possible on adoption in progress for a UML 2.0 specification.

  • UML 2.0 Infrastructure (RFP ad/00-09-01).
  • UML 2.0 Superstructure (RFP ad/00-09-01).
  • UML 2.0 OCL (RFP ad/00-09-03).

The following specifications are currently in progress, at various levels of completion in their RFP process. Depending on their stage of completion at time of submission to this RFP, they may include modeling elements or technical approaches that may be incorporated in a Systems Engineering RFP.

  • UML Profile for Modeling QoS and FT Characteristics and Mechanisms (RFP ad/02-01-07). This profile for Quality of Service and Fault Tolerance builds on and extends the adopted UML Profile for Schedulability, Performance, and Time.
  • UML Testing Profile (RFP ad/01-07-08).
  • Business Process Definition (Business Enterprise Integration Task Force; RFP not yet issued)
  • Business Rules (Business Rules Working Group; RFP not yet issued)

The following specifications provide a framework for interchange of models that are captured in a UML modeling framework. They are listed here to indicate the additional specifications on which the effective use of a UML Profile for Systems Engineering for model interchange would depend.

  • XMI Metadata Interchange (XMI) Specification (formal/2002-01-01 and formal/2001-04-03).
  • XMI Production of XML Schema (ptc/02-06-01).
  • MOF 2.0 XMI Specification (RFP ad/01-11-13).
  • UML 2.0 Diagram Interchange (RFP ad/01-02-39).

6.4Related Activities, Documents and Standards

The web site of the OMG Systems Engineering DSIG at has extensive background and material on the UML for Systems Engineering activity and its relation to larger systems engineering efforts being coordinated by the International Council on Systems Engineering (INCOSE).

(Here is some related text from the SE DSIG web page.)

Relation to AP-233 effort. The SE DSIG effort is intended to be closely aligned with the on-going ISO AP-233 standard activity [AP-233]. AP-233 is focused on developing a data interchange standard for systems engineering, which is intended to provide a neutral data format to exchange systems engineering information among tools. The ISO AP-233 project is a working group of TC-184 (Technical Committee on Industrial Automation Systems and Integration), SC4 (Subcommittee on Industrial Data Standards), and is part of the larger STEP effort, which provides standardized models and infrastructure for the exchange of product model data. The result of this effort will be part of the existing ISO 10303 standard that will provide an “Application Protocol” for Systems Engineering. One of the joint SE DSIG and AP-233 tasks, is the development of the Systems Engineering Conceptual model, which is intended to help algin the requirements for SE UML and the AP-233 data standard.

Relation to Systems Engineering Process Standards. The SE DSIG effort is focused on establishing standards for system modeling. The system modeling is generally the result of implementing the activities and techniques which are defined by the applicable systems engineering process and methodology. There are several systems engineering process standards, including ANSI/EIA 632, IEEE 1220-1998, and ISO/IEC 15288. Each of these process standards defines the primary activities, which must be performed to implement systems engineering. The”Overview of the ISO/IEC 15288 System Life Cycle Process Standard” at presents one example of a process standard (provided by James N Martin to INCOSE on July 12, 2002).

There are also a variety of methodologies for implementing the systems engineering process, which include both structured and object oriented methodologies. Some examples of systems engineering methods are referenced in the SE UML RFI Responses at and many others can be found in the INCOSE systems engineering handbook available from the INCOSE website at

(All web site and document references to existing source materials or other background should be provided in this section. OMG provides its own set of references in Appendix A, but all references specific to systems engineering should appear in this section. Here is an outline of reference categories that currently appear in the SE UML Requirements Analysis; these references may be assembled largely from this source, or the RFP could point to the document where the detailed reference listing can be obtained.)

References: (to be completed)

SE Concept Model and Semantic Dictionary

SE RFI and RFI Responses (and also earlier responses to UML 2.0 RFI also addressing SE requirements)

Reference Papers

SE Process Standards

Web Sites (SE DSIG, AP-233, INCOSE)

SE UML Requirements Analysis

6.5Mandatory Requirements

(This section is currently being drafted as Appendix A of SE UML Requirements Analysis V0.4 document. This appendix consists of simple declarative statements about capabilities that an SE UML specification should support. The entire text of that appendix will be included verbatim in this section once it is finalized there.)

6.6Optional Requirements

(Currently all requirements have been included as mandatory with no attempt to divide them into optional conformance categories or levels. Specifications are also expected to address all the requested capabilities rather than any partial response. Requirements may be added to this section only if further review of the requirements indicates less than the mandatory support that has currently been assumed. One example of a potentially optional requirement which has been mentioned is that a system model be capable of enough detail to be directly executable or fully simulated.)

6.7Issues to be discussed

Describe the issues that proposals should discuss. Issues to be discussed shall be stated in terms of phrases such as:

“Proposals shall discuss how... ”, or
“Proposals shall include information on”, or
“Proposals shall provide the design rationale for...”.

These issues will be considered during submission evaluation. They should not be part of the proposed normative specification. (Place them in Part I of the submission.) The issues to be included may be derived from the issues in the SE UML Requirements Analysis V0.4

(To be provided. By including any issues, the RFP indicates that some discussion of each issue is expected in any response, such as how the proposal may enable some larger goal, but that this discussion is expected to be separate from the specification of basic elements themselves.)

6.8Evaluation Criteria

Conformance to the mandatory requirements along with consideration of the optional requirements and issues to be discussed are implied evaluation criteria. RFP authors should describe any additional criteria that submitters should be aware of that will be applied during the evaluation process.

Proposals will be evaluated against the mandatory and optional requirements, above, the explanations requested under issues to be discussed, and the extent to which they address the business needs as described in sections 6.1 and the scope as described in section 6.2.

Additionally, the following evaluation criteria will be considered: (From SE UML Requirements Analysis document. Each point should probably be consolidated into a single statement or paragraph for this RFP)

6.8.1Ease of use

The language should be readily interpreted and used by a broad range of technical and non-technical stakeholders, with a reasonable amount of instruction and practice.