Why Reconsider Systems Engineering Methodology?

Key Issues Affecting the Engineering Process Engineering for evolving product families, product and production life cycles Personnel mobility Increasing System Complexity Shorter time to market and reduced design costs Communication between disciplines & blurred boundaries Requirements on Engineering Processes Design reuse supports shorter time to market and engineering for product families. Better system-wide documentation of design process and product supports engineering for production and product lifecycles, system compexity, and personnel mobility. Semi-automated systems for requirements analysis, validation and verification support increasing complexity, engineering for evolving product families, etc., shorter time to market and reduced design cost Emergence of a New Systems Engineering Methodology Software engineering discipline has responded by developing new Systems Engineering methodologies and tools. How can we expand this effort to cover other engineering disciplines and enterprises?

New System Engineering Methodologies Use object oriented models both for systems development, and to describe the engineering process itself. Use automated tools to connect the systems models directly to the systems that they model, (i.e. source code) Benefits: Heirarchical models of system structure and function lead to efficient understanding of complex systems Well defined interfaces between system components improve requirements tracability, design validation and system verification Why it works in Software Engineering Object oriented systems system models mesh well with Object oriented software development methods Software projects produce a uniform product: lines of lines of source code, pages of documentation, and training materials. The Systems Engineering ideas evolved in response to problems in Software Engineering What needs to be changed for other engineering disciplines Find appropriate modeling languages for other engineering domains Find ways to bridge the language divides between disciplines Find ways to integrate Systems Engineering support tools with the design, manufacture and test tools of different disciplines

What functions does Systems Engineering handle?

Activities that Systems Engineering should support Requirements Management Design Validation and Verification Searchable archives of System Documents System and component models Drawings and CAD representations Engineering analysis and computational models Decision procedure & and design rationale Manage the design change process Manage fault reports, analysis and resolution Manage system budgets Manage the work process schedule Properties that are important in support systems Traceability User navigation Uniform interfaces and standardized information formats Support systems management separate from content management Support automated query by Systems Engineering tools Universal access Extensive support for reuse Implementation issues Content and quality assurance provided by "engineers in the field" Education and training Information management costs apply to project budgets Integration with existing and future CAD and project management systems Information from broad variety of changing data sources Tools to mine information from existing data formats Tools to convert between data formats

System Engineering Models

Object Oriented Systems Modeling Formal Models Meta Model: The rules for making a model (example UML) Ontology: A set of model building blocks (the entities in a UML model for a database system) What is a formal model? A choice of Meta Model and Ontology determines a model space. Some guidelines for designing model spaces: Keep the rules simple Use many model spaces adapted to specific domains Use translation tools to move between domains "English Language" representation of OO models provides descriptive semantics. This mimics the way that we think about systems, but makes for long-winded descriptions of system structure. Diagraming notation provides a visual syntax that retains the formalism of the language, This makes models easier to capture, and understand. Standards such as UML provide a formal specification, called a meta-language, that secifies what constitutes a valid model description in a particular application domain. The standard also links the diagraming notation with the language representation. (In the case of UML the domain is software engineering) In the example presented in the next slide, the language supports three entities: classes, objects and relations. The language defines special relations between classes: generalization and aggregation, and a relationship between objects and classes, instantiation. It also specifies that interactions between objects are restricted to the relations that are defined for the classes that the objects represent. The specification of the formal modeling languages and ontologies for particular problem domains provides support for: Efficient storage and communication of all valid systems models Tools (such as requirements tracing tools) that can draw inferences about a model based rules that are founded in the model structure. Tools that can use mappings of ontologies to translate models from one domain to another, e.g. a mechanical system model to a thermal system model.

Modeling Languages and Diagramming Notations -- UML

A Cartoon Example: The problem domain is Bedrock Department of Transportation, Accident Reconstruction Office. Meta model elements classes objects relations attributes special relationships Generalization Aggregation Instantiation Meta model rules Each object instantiates a single class Let A, B and C be classes, and let r be a relation. If A generalizes B, and if r connects B to C, then r connects A to C Notation for Meta Model Elements The Ontology The class person has a name attribute The class vehicle has a license plate attribute The class vehicle is an aggregate of a drive-train, a body, an electrical system, etc. The class vehicle is a generalization of the classes truck, car, and motorcycle A person can relate to a vehicle as a driver, a passanger. A vehicle can collide with a person The meta model A specific model English language representation: The person with name Fred is the driver of the car with license plate AAA 111 The person with name Wilmer is the passenger of the car with license plate AAA 111 The person with name Barney is the victim of a collision with the car with license plate AAA 111 Diagram representation: Notes: The meta language elements are quite general. The generalization and aggregation relationships support scalable models. The part of the language that is domain specific is the ontology. To develop this material for a short course we need to find an example that is realistic and meaningful to the target audience e.g. mechanical engineers working on systems at Lockheed Martin. Do you have an example that we can slot in place?

The Integration Problem

The Integration Problem Achieving the listed objectives for comprehensive systems engineering support requires integration of the following elements: The systems engineering model The evolving tools that support the systems engineering effort Search tools Presentation tools Tools to support dependency tracing Automatic budget checkers, and design verification tools The evolving tools that support specialized disciplines CAD tools Project planning tools Special modeling tools (Mechanichal analysis, Thermal analysis etc) Legacy documentation and models In addition, the integration has to occur within the IT infrastructure of the organizations that support the engineering effort. The monolithic approach that is represented by tools such as Rational Rose's software engineering tools is not likely to be successful for more general Systems Engineering support Web based technologies that use distributed co-operative organization rather than strong centralized control seem to be a much better match.

Limitations of Present-Day Requirements Engineering Tools

Critical Assessment of Present-Day Systems Engineering Tools (e.g., DOORS and SLATE). How do we capture, represent and use knowledge through requirements engineering activities? Figure: Requirements Engineering WBS and Industry Toolset Weakensses. (For details, see Ramesh and Jarke, 2001) Specific Limitations of Present-Day Tools (Selberg, 2002) Thick Descriptions. Current tools lack the ability to store informal representations (i.e., so-called thick descriptions) of systems conveying information along subtle or implied lines. Model Driven Trace Capture and Usage. Current tools lack mechansms for "easy linking" of models into the design environment (e.g., SLATE). Abstraction Mechanisms. Current tools lack the ability to search and explore requirements at various levels of abstraction. Inference Services. Current tools are incapable of analyzing requirements for completeness or consistency. Search mechanisms are limited to keywords, which can be limiting for custom jargon in multidisciplinary and multilingual projects. Observations The glue that holds the system together is the basic modeling methodology. The loose coupling between knowlede domains and between CAD applications, and between knowledge repositories supports robust ad-hoc incremental development. Basic web-based infrastructure, which includes web-servers, application servers, and web browsers is already ubiquitous. References Ramesh B., and Jarke M., "Toward Reference Models for Requirements Traceability," IEEE Transactions on Software Engineering, Vol. 27., No. 1., January 2001, pp. 58-93.

The Semantic Web Layer Cake

Figure: The Semantic Web Layer Cake (Berners-Lee, 2000). The Semantic Web is an extension of the current web. It aims to give information a well-defined meaning, thereby creating a pathway for machine-to-machine communication and automated serives based on descriptions of semantics. XML files and web resources capture objects and classes. RDF describes relationships between objects and classes. Ontologies provide a formal conceptualization (semantic representation) of a particular domain shared by a group of people. Ontology-based applications will be built on top of the Semantic Web infrastructure (i.e., XML, RDF and ontologies)

Transfer of Semantic Web Technologies to Requirements Engineering

What is the minumum level of Semantic Web Technology that can mitigate (and hopefully overcome) limitations in present-day tools? Figure: Requirements Engineering WBS (Create Branch) to Semantic Layer Cake (Selberg, 2002). Figure: Requirements Engineering WBS (Use Branch) to Semantic Layer Cake (Selberg, 2002). References Selberg S., "Requirements Engineering and the Semantic Web," M.S. Thesis, Institute for Systems Research, University of Maryland, College Park, MD 20742, April 2002.

Principles of Development for Standards Processing

For engineering systems of the size and complexity envisioned in the near future, designs will need to satisfy standards and regulations from multiple disciplines. The principles that will drive this development are as follows. There needs to be a clean separation of the design environment from the suite of programs that checks the conformance of a design to multiple design standards. Because design standards evolve over time, the standard processing program that models, executes and interprets multiple standards should be decoupled from the standards themselves.

Using STEP to Exchange Product Model Data

Standard for the Exchange of Product Model Data (STEP) Figure: Levels of Data Transfer Between Models Standardized protocols such as STEP provide the exchange formats between tools in disparate domains.

Information Interoperability and Transformation with STEP and XML

Transactions of Data Packaged in Standards Figure: Information/Data Interoperability with STEP and XML Engineering software systems such as Pro Engineer, Modeling packages etc. sit behind application servers that links to documents and services that these applications provide. Transforming Information/Data with XML Technology Figure: Transforming XML Documents with XSLT Points to note: Style sheets provide model and data translation. Style sheets also provide translation from the model to formats for Web presentation of information.

Traceability of Requirements to System Parts

This graphic is adapted from XML.com.

Opportunities for Joint Work

Research Explore the extent to which XML and RDF technologies can describe requirements (suitable for 3D mechanical models) and model requirements traceability. Understand how to write requirements at each layer of the STEP standard. Curriculum Development We propose a 1/2 day short course to teach the following: Explanation of Systems Engineering methodology Fundamentals of systems modeling from the point of view of the end-user, including: Definition of model spaces that are adapted to the information that characterizes problem domain (such as 3-D geometric relationships) Tools for model creation Tools for extracting models from legacy resources Integration with existing design software such as 3D-modelling applications (Pro-Engineer) How a systems engineering tool (such as a requirements management system that we will demonstrate) uses the systems models. Our emphasis will be on two issues: Teaching systems modeling techniques as a communication tool. Demonstrating how modeling techniques combnied with web-based system engineering tools improve the Systems Engineering process. We stress again the importance of developing the curriculum in conjunction with well chosen examples that faithfully present problems that the intended audience currently face.