CIMdata PLM Industry Summary Online Archive

18 October 2012

CIMdata News

Systems Engineering: At Teamcenterʼs Core: a CIMdata Commentary

Key takeaways:

  • Lack of resources, increasing product and supply chain complexities, and increasing customer and regulatory demands are driving the need for and adoption of systems engineering.
  • Systems engineering and PLM are complementary, and companies that use PLM to enable systems engineering will have a competitive advantage.
  • The current release of Teamcenter delivers comprehensive systems engineering support built on years of broad and deep expertise and functional capabilities.
  • The future of product development productivity and competitiveness demands that systems engineering be supported.

In today’s hyper-competitive business environment, companies across almost all industrial sectors have no choice but to find more efficient and effective ways to deal with the lack of resources, increasing product and supply chain complexities, and increasing customer and regulatory demands. Exploiting the product-development discipline of Systems Engineering and enabling it with the information and process management capabilities offered by today’s leading Product Lifecycle Management (PLM) solutions is proving to be a truly innovative strategy. For many, this strategy is a new way of working to manage the growing complexity of product development and the associated product lifecycle, to smooth the incorporation of emerging technologies, and to leverage the combination of systems engineering and PLM into a sustainable competitive advantage.

Today’s Systems Engineering Push

Systems engineering is a cross-functional methodology created specifically to manage all of the “pieces” of complex projects and products—specifications, designs, and analyses; verifications and validations; hardware and software; data and personnel; procedures and operations; and manufacturing facilities, production systems, and industrial engineering, to name a few. This methodology is a comprehensive and holistic approach to develop, deliver, and support optimum product solutions. At its core, it defines and associates requirements to functions, functions to logical representations, and logical representations to physical designs—providing an architectural framework for the downstream physical implementation of all the systems associated with the product, including manufacturing, support, and ultimately recycling.

As an interdisciplinary field of engineering, systems engineering focuses on how complex engineering projects and their associated deliverables (i.e., products) should be designed and managed over their lifecycles. Beginning at Bell Labs in the 1940s, systems engineering was developed to address the difficulty of designing complex systems, where the properties of the system might differ greatly from the sum of the properties of its parts. The discipline has notably been adopted in aerospace and defense.

The International Council on Systems Engineering (INCOSE) is a professional society, created to address the need for improvements in systems engineering practices and education. Since about 2000, INCOSE has championed the development of SysML. Since 2007, they have promoted model-based systems engineering (MBSE) as part of their 2020 vision for systems engineering.

A core idea of MBSE is to move the practice of systems engineering from a document-centric to a model-centric paradigm. The system is described in a modeling language like SysML, and different domains (e.g., manufacturing, design, analysis, or marketing) access the single model, though they each may have different views of the information. In the old paradigm, each domain had its own documents, and synchronizing the documents to maintain the dependencies and keep them consistent was a major issue.

MBSE is seen as a required evolution of the practice of systems engineering to handle increased system complexity and the integration across disciplines like mechanical design, electronics, software, and controls. Among the benefits of this approach are:

  • Improved quality—e.g., early identification of requirements issues, enhanced system design integrity, fewer errors during installation and training, and more rigorous requirements traceability.
  • Increased productivity—e.g., improved impact analysis of requirements changes, reuse of existing models to support design and technology evolution, and automatic generation of documentation.
  • Reduced risk—e.g., improved cost estimates and early and ongoing requirements validation and design verification.

State of Adoption

Unfortunately, in many of today’s manufacturing enterprises, systems engineering and PLM are often not seen as complementary, and beyond aerospace and defense, and some automobile manufacturers, systems engineering isn’t a common way of working. Fundamentally, most companies design parts and components, and then integrate them, instead of designing systems. In addition, they use documents and spreadsheets to manage requirements, and not “live” interactive models to describe and simulate their products that are often comprised of systems of systems.

CIMdata research and experience indicates that requirements, which are a critical component to enabling a robust systems engineering practice, are generally not well understood. This is complicated by the fact that they must be optimally partitioned across the complete product, including mechanical, electronic, software, and other designed elements. Companies can no longer just build the next version smaller, thinner, lighter, stronger, or “better” on some other metric of interest to customers, to meet their requirements. They are reaching their limits of understanding regarding the relationships between different parts of their products due to the widespread use of spreadsheets to manage requirements. The increasing software and electronics content in products in many markets is making product development, manufacturing, installation, and support even more complex—in some cases beyond what is tenable. In our industrial consulting, CIMdata sees many symptoms of this problem:

  • Unstated or poorly defined requirements—not clear, concise, and valid.
  • Requirements scattered around the organization—no single source of the truth.
  • Requirements accepted from any sources—no matter their validity.
  • Poor, or no, management of requirements—often leading to scope creep.
  • Inability to validate that a design will meet the approved requirements—before, during, or after build.
  • Tests prove what was built—rather than what should have been built.
  • High levels of re-work—throughout project execution.

Systems Engineering and PLM

Systems engineering enabled with PLM can sort out product development difficulties that have existed for many years. Often these challenges result from a lack of effective strategies to make ongoing product development visible at the extended enterprise level (i.e., across the various organizations and disciplines that are responsible for product development). Enabling systems engineering with PLM gives users new decision-making tools to address these and other challenges.

PLM-enabled systems engineering empowers users to put the entire extended enterprise on a solid footing to optimize a product for its lifecycle. New-product managers struggle with conflicting product requirements, short-lived market windows, and rising demands for regulatory compliance. They need all the help they can get—in particular, a mechanism that helps them to quickly and effectively perform multi-discipline business-impact and trade-off analyses. PLM provides the best way to ensure that the product and the associated lifecycle experiences are optimized.

Using holistic systems modeling methods enabled by PLM, engineers can better manage the design and lifecycle business tradeoffs. This lets them design at the systems level and to synthesize subsystems. PLM manages the requirements, and when enabling systems engineering, it also tracks design changes against requirements and the relationships between components, subsystems, and systems against all of their requirements; and tracks all of the inputs from those who are responsible for design, production, and support.

Enabling systems engineering with PLM holds forth the promise of the single logical source of the truth. The greatest challenge engineers face is to find the necessary information and verify its source and accuracy. This problem dates back to the dawn of the Industrial Age. A single logical source of the truth, particularly at the project level, multiplies any project team’s effectiveness. A single version of truth is critical for effective decision-making and business success.

Up to this point we have discussed requirements of new products as if they were static. They are not; quite the opposite. In every successful business, new-product requirements are dynamic. That is partly why those requirements are often unclear, unstated, scattered, and/or mismanaged—they are constantly in flux. The extension of product development beyond engineering and the explosion of social media have added numerous small cascades of information and opinion to the process. As it is usually implemented, systems engineering is not especially well equipped to deal with these externally imposed cascades. PLM is however, due to its internally consistent tool sets and interrelated data.

Systems Engineering and Teamcenter

Siemens PLM Software’s (Siemens) understanding and support of systems engineering is both broad and deep. Siemens’ systems engineering roots date back to the early 1990s and the SLATE (System Level Automation Tool for Engineers) product, which was developed at Texas Instruments to help design and manage complex electronic systems. The technology was later purchased by SDRC to help manage the fuzzy front end of complex products being developed by their customers. When EDS purchased SDRC in 1999 and combined it with the UGS organization, the SLATE technology was merged with UGS’ products to integrate systems engineering with the product lifecycle. This merger was accomplished in multiple incremental steps, with the introduction of the Teamcenter Unified platform in 2007 providing a major breakthrough.

The 2007 Teamcenter release represented Siemens’ new PLM platform based on a Services Oriented Architecture (SOA) and a new Business Modeler Integrated Development Environment (BMIDE). As part of the 2007 release, Siemens took the first step towards Model-Based Systems Engineering—a core component of what Siemens commonly calls its “Systems Driven Product Development” strategy. This release took advantage of the core requirements management capabilities that earlier versions of Teamcenter supported, combined with the new platform’s inherent support of requirement data items as part of its core data model. The platform’s core capabilities introduced in 2007 allowed users to capture and share requirements using Microsoft Word, create properties, manage their evolution, assign them to product configurations, and link them to other objects—a major step forward in integrated systems engineering support. With this approach, requirements were linked and traceable as part of the overall product lifecycle, and they could be linked to specific product configurations—as well as participate in structured workflows, change processes, and project schedules. This allowed Teamcenter users to assess the impact of requirements changes and understand what requirements would be affected by proposed changes. While the Teamcenter Systems Engineering module was still a standalone application with this release, requirements were part of Siemens’ new integrated PLM platform.

With the release of Teamcenter 8, Siemens further expanded core-requirements management capability to include “live” integration with Microsoft Word and Excel, which enabled users to capture, edit, and manage requirements from either Teamcenter or the native Microsoft applications, and the changes were automatically reflected in both Teamcenter and Microsoft. To help share decision support information such as requirement intent, assumptions, trade-offs, and concerns with downstream stakeholders, “Sticky Note” functionality was added. In addition, capabilities were added that exposed requirements and the multitude of dependencies and relationships in Teamcenter’s graphical relationship browser. To address the demands of globalized design and manufacturing environments Siemens also incorporated multi-language support in the release.

With its release of Teamcenter 9, Siemens made another crucial step forward. This release introduced the integration of systems engineering and requirements management into the product lifecycle, leveraging “live” integration with Microsoft Visio as the embedded systems diagramming tool to create Teamcenter objects, connections, and ports (i.e., signals and messages), and to establish trace links from requirements to functional elements. As part of its “open” strategy, Siemens also introduced Teamcenter integrations with MathWorks MATLAB and Simulink, further leveraging its extensive data model. With these capabilities, Teamcenter managed all the models and relationships with other parts of the product. This release of Teamcenter enabled all three main components of Siemens’ Systems Driven Product Development strategy: requirements-driven product development with full configuration control; a model-based design approach for defining, simulating, and optimizing; and integrations to third-party supporting tools for all the necessary lifecycle domains.

Siemens’ current release of Teamcenter, Teamcenter 9.1, leverages a data model that provides the ability to capture, manage, and share all the functional, logical, and physical implementation information generated in each design domain, as well as the appropriate dependencies, allocations, and associations between design objects. These relationships and cross-domain dependencies provide the traceability needed to identify the specific subsystems, domains, configurations, data, and design objects impacted when changes are proposed anywhere in the product lifecycle.

The current release of Teamcenter Systems Engineering has come a long way from its roots in SLATE. Teamcenter Systems Engineering represents a highly integrated PLM-enabled solution. CIMdata’s research and experience indicate that the potential payoffs for companies that utilize such an integrated approach can be significant. The benefits from the convergence of systems engineering and PLM show up in hard numbers as well as in “softer,” less readily calculable ways. The largest of the hard numbers lies in the single logical source of the truth. The huge amounts of time engineers spend in searching for and validating information can be cut by as much as ninety-five percent. That could double or triple the productivity of individual engineers in creatively solving problems. The most dramatic of the “soft” payoffs is better collaboration. By itself, collaboration can do more for the sustainability of the enterprise than any dollars-and-cents return on investment (ROI). After all, the benefits of collaboration add to margins year after year. An ROI payback goes to the bottom line, but only once. A final gain when systems engineering and PLM are joined, as they are in Teamcenter, is reducing hidden risks. In the absence of sound enterprise information asset strategies, information and valuable insights can be lost. This can impose huge costs on future products because of poor decision making, repeated mistakes, and lessons learned that are not passed on.

Where to Begin

For many industrial organizations the concept of systems engineering, is just that, a concept. While many are talking or thinking about it, most really don't understand how to go about defining and implementing the organizational, process, and technological changes necessary to move from a mindset of part and component design and system integration, to one where the product is designed and optimized from a systems and lifecycle perspective. As with other approaches that require a significant set of changes, companies need to first focus on the least risky improvements that lay the foundation for future and more significant improvements. When it comes to systems engineering, one of the first steps in what is usually a multi-year journey, is to define the organization’s vision, goals, and objectives related to systems engineering (i.e., what is the organization trying to achieve and why). Next the organization should map out the main steps to reach its vision—usually this will be the identification of the organizational, process, and technological changes that will be required, and the expected ROI. Once these two critical steps have been completed, the organization can begin executing its plan, making adjustments as required.

Finally, there are a few things that an organization should consider as it embraces a systems engineering approach:

  • Don’t try to do everything at once—organizational, process, and technological changes and their adoption will take time.
  • Start with defining and managing requirements—they are the key foundational element of systems engineering.
  • Always look to enable people, processes, and technologies in support of systems engineering—embracing and enabling systems engineering is a complex journey that impacts all of these factors and it will take time and energy.

Adoption of systems engineering across industrial sectors is minimal today, but it is expected to grow significantly over the next five to ten years. If a company hasn’t considered adopting the core philosophies, then it is critical that they do so in the near term. The future of their product development and business competitiveness demands it.

About CIMdata

CIMdata, an independent worldwide firm, provides strategic management consulting to maximize an enterprise’s ability to design and deliver innovative products and services through the application of Product Lifecycle Management (PLM). CIMdata provides world-class knowledge, expertise, and best-practice methods on PLM. CIMdata also offers research, subscription services, publications, and education through international conferences. To learn more about CIMdata’s services, visit our website at http://www.CIMdata.com or contact CIMdata at: 3909 Research Park Drive, Ann Arbor, MI 48108, USA. Tel: +1 734.668.9922. Fax: +1 734.668.1957; or at Oogststraat 20, 6004 CV Weert, The Netherlands. Tel: +31 (0) 495.533.666.

Become a member of the CIMdata PLM Community to receive your daily PLM news and much more.

Tell us what you think of the CIMdata Newsletter. Send your feedback.

CIMdata is committed to your privacy. Your personal information will never be sold or shared outside of CIMdata without your express permission.

Subscribe