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 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.
Systems Engineering Recharges Electronics Industry
For electronics components destined for use in larger system, requirements management determines success or failure.
When you achieve a certain level of complexity, it is no longer possible to continue to develop products and to have a global understanding of them without using systems engineering. This is particularly true of electronics used in defense, automotive, and medical devices or applications.
Electronics designers and manufacturers produce discrete stand-alone products for commercial markets, but an even larger number of products are sold to add value and functionality to larger systems. Systems engineering ensures the necessary requirements have been considered so the product can function well inside other systems.
For example, a disk-drive manufacturer must think about how its product is going to be used, what people want in terms of power management or form factor. The manufacturer not only has to systems engineer its own product, it has to systems engineer all the possible uses of its product in someone else’s system. You can have the fastest, most reliable disk drive in the world, but if it is an eighth of an inch too high to fit into the next generation of laptops, you might as well close up shop.
According to Dassault Systèmes, adoption of systems engineering has grown quickly in the electronics industry. This is particularly true of the domain where complex electronics are embedded in systems to control the interaction of the equipment with the external environment. —TK
“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.
Diagram 1: Designers should re-evaluate design decisions as an ongoing process, with multiple parallel loops to improve system architecture and performance. Courtesy of Siemens PLM Software
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.
International Council on Systems Engineering
Siemens PLM Software
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 DE-Editors@deskeng.com.