Systems Engineering Offers Big-Picture Design

By Tom Kevan

Systems are becoming more complex, and the traditional ways of driving product development and analyzing system requirements no longer work. In most cases, “the way we’ve always done it” does not adequately consider the product as a whole nor make the customer’s requirements the top priority.

Figure 1: This functional diagram shows how a systems simulation depends on a functional modeling perspective, integrated with requirements and logical and physical models. Courtesy of Dassault Systèmes

It’s not just the products that have become complex, but product development itself. The technologies used in devices are more difficult to master. The functional complexity of products has exploded. New devices must now meet an elaborate array of regulatory requirements that include environmental, safety, and trade guidelines. And the nature of design teams has become more heterogeneous. Today, it’s not unusual for team members to be distributed throughout the world and come from multiple engineering disciplines. The answer to these challenges is a big-picture view and understanding of the product and how its parts work together. “As products have gotten more complex, we’ve had to look at the product in more totality,” says Kenneth Amann, director of research for CIMdata. “We’ve had to take a more holistic view of it to truly understand it and to make sure the tradeoffs we are making in the design are proper.”

  Systems Engineering
Systems engineering provides that big-picture view with an interdisciplinary approach that focuses on work processes and tools to manage complex product development and to ensure customer needs are met. The objective is to consider product development in a holistic way (see Figure 1) and to achieve the optimal architecture of the system, justified in terms of operation, cost, performance, and capabilities.

Figure 2: The mapping of allocations between parameters on physical parts to requirements on functional and logical models in Teamcenter, enables the use of independent groups of parts in the design of multiple products. Courtesy of Siemens PLM Software

Design decisions are reached after evaluation of alternative approaches and iterative testing, validation, and verification early in the development process (see Diagram 1, page 18). And systems engineering is concerned with the entire lifecycle of the product, so it encompasses downstream concerns such as manufacturing optimization, interoperability,  maintenance and upgrades, training, recyclability, and disposal.

  Today, companies cannot survive unless they can quickly deliver high-function products to market at a competitive cost. And because everyone is striving to achieve these goals, companies have to work harder to differentiate themselves from their competitors and one clear way to do that is to offer complex capabilities in products.

  The biggest technical factor driving the adoption of systems engineering is that widespread complexity. “I was doing systems engineering on satellite collection systems 10 or 15 years ago, but today you have the same level of complexity in the cell phone hanging off your belt or the MP3 player you have in your pocket,” says Bill Boswell, a Senior Director of Teamcenter for Siemens PLM Software.

Figure 3: Teamcenter builds a structure of requirements that can connect live with Microsoft Word. Courtesy of Siemens PLM Software

With complex systems, it is harder to predict and simulate a product’s behavior. Someone has to be looking out for the overall satisfaction of the product requirements, so there is a need for people that have a big-picture view of the product and an understanding of how the components and subsystems work together. In the past, silos of knowledge and the limited number of engineers with cross-functional domain knowledge stood in the way of achieving these goals, but systems engineering addresses these issues.

Figure 4: This screenshot shows the logical diagram of a system (left); the V6 solution’s use of the open, industry-standard Modelica systems modeling language (right top); and a state chart of the system in question (right bottom). Courtesy of Dassault Systèmes

Translating and Tracing Requirements
A systems engineer’s most fundamental task might be to define the product’s requirements. The idea is to start with the voice of the customer, break down the requirements, and build a tree that will help you convert something ambiguous into specific, measurable requirements that you can then build to.

“Usually, customers are not engineers. They typically say something like, ‘I want the door to sound solid when I close it,’” says Patrick Hale, past president of the International Council on Systems Engineering. “You intuitively have a feel for what that means, but you can’t design to that intuitive feeling. You have to somehow turn that into a set of engineering requirements that people can design to, measure, and ensure that it meets the customer’s intent.

After translating the customer’s needs, you should be able to trace the requirements across the various development steps (see Figure 2, page 17). This is especially true of requirements relating to the product’s capabilities, architecture, implementation, integration, and test and validation plans. If you are going to change the requirements, you have to consider the effect on the architecture and the implementation. You also have to update how you are going to test and integrate the system to verify that you comply with the requirements. When traceability is incomplete or absent,  projects suffer.

“If you look at research, you see that about 40 percent of the projects fail due to a lack of requirements traceability to the different capabilities,” says Laurent Cherprenet, director of high-tech industry for Dassault Systèmes. “If you cannot comply with some requirements in the software domain, you are also going to impact requirements in other domains. And in the end, your product is not going to fulfill the overall requirements….”

Interfaces, Interactions,   Integration
Systems engineering places a high value on understanding the interfaces and behaviors you expect to see in the system. According to Hale,  NASA believed “the role of systems engineering differs from design engineering in that it deals with the relationships of the thing being designed to its environment and subsystems rather than with the internal details of how it is to accomplish its objectives.”

  This translates into understanding how the intended and unintended interactions of all of the components and subsystems will occur and whether they will help satisfy the customer’s needs. Increasingly, this takes place in a model-based environment, where long before you’ve done detailed design or built a prototype, you try to capture the potential—positive and negative—behaviors at a conceptual level.

The importance of understanding the interfaces through modeling and simulation is spelled out by recent research. “Nearly 50 percent of projects fail due to poor system architecture validation,” adds Dassault’s Cherprenet. “Most of the issues are relative to the poor specification of the interfaces between the different components of the architecture, especially how they are going to communicate between software and electronics.”

  Two leading providers of systems engineering software tools are Siemens PLM Software and Dassault Systèmes. Both of these vendors provide integrated interdisciplinary platforms that facilitate a holistic understanding of products and include data management and modeling and simulation functionality (see Figure 3).
Siemens’ Teamcenter systems engineering module includes Web-based groupware collaboration and information-linking functionality that integrate with requirements management capabilities. The software enables alternative design evaluation and optimized design tradeoffs.

Tools of the Trade
“The module has tools that help you define system architecture, interfaces, and options, and track pieces throughout the design process, helping you create the cross-domain systems definition,” says Siemens’  Boswell.

Dassault’s virtual design solution, CATIA, captures and manages product requirements with full traceability throughout the product development cycle, from functional architecture and logical breakdown to physical design and testing (see Figure 4). Components from multiple disciplines (e.g., mechanical and electrical) are modeled on a common platform to enable dynamic simulation of the complete system. While leveraging numerous capabilities from a broad PLM platform, the functionality is aggregated in CATIA V6. The CATIA Systems domain includes solutions for architecture design,  logical 3D architecture, control and logic modeling, logic code generator, and dynamic behavior.

More Info:
CIMdata

Dassault Systèmes

International Council on Systems Engineering

Siemens PLM Software

Teradyne

Contributing Editor Tom Kevan is based in New Hampshire and is DE’s mechatronics, PLM, and systems expert. Send your comments about this article to [email protected].