Systems Engineering %%%%

With the ever-increasing adoption of “smart,” mechatronic products requiring a combination of a mechanical, electronics, and computer engineering, the discipline of systems engineering has never been more important. Given the complexity of modern products, systems engineering’s methodical approach for product definition and realization is being done by most companies whether they realize it or not.

The systems engineering process flow is often represented as a “V” diagram and as with any process there are many variations of it (to get a quick sample do a Web image search of “systems engineering”). Rather than presenting yet another “V” diagram to gain an understanding of how to better manage a systems engineering process, it is simpler to just focus on the two main aspects of systems engineering and its main sub-processes:

Product Definition

Requirements development
Functional breakdown and logical analysis
Product design

Product Realization

Sub-system integration
Verification that requirements are met
Validation of product behavior

As mentioned, most companies developing mechatronic products do perform systems engineering sub-processes – some more formally than others. For instance:

With software, it is very common to see solutions that manage detailed requirements and their associated test cases for verification. Teams developing mechanical and electronics hardware, the need still exists, but adoption of formal tools has not been as common.

Many companies organize their bills-of-material based on a functional breakdown to facilitate the eventual sub-system integration from various engineering disciplines as designs are completed. Unfortunately, this approach fails to properly capture the logical relationship between sub-systems and how they interact.

Another common issue is that companies rely too much on costly physical prototypes, or even worse, early production runs, to validate if the final user/consumer will accept the product. Companies are not taking advantage of modern simulation and product behavior modeling software to validate product performance enough early in the product development process as the system functional breakdown and product design occurs.

Lastly, even if every one of these sub-processes are pursued, it is often with unique tools and systems that do not allow for the easy flow and exchange of information between product development participants.

Considering the status quo and the issue highlighted above, what is really needed for effective systems engineering is:

Capture requirements for hardware and software.
Define test cases to verify that requirements are fulfilled.
Model a product’s sub-systems based on function and their logical relationship to one another.
Virtually model product behavior to validate that a system meets end user expectation.
Perform product design with kinematics and/or virtual simulation to further validate and verify system performance.
Ideally perform #s 1-5 with tools that provide easy data exchange and traceability between the various stakeholders from requirements through product design, verification, and validation.

The traditional “V” diagram falls short in properly conveying how this systems engineering flow should be executed because most do not convey feedback loops and parallel activities. So, rather than being constrained by the “V” shape just because “verification” and “validation” are the goals, the following can be used to convey a systems engineering target.

Getting-Started-with-Systems-Engineering

Pursuing the full scope of systems engineering processes may seem daunting, but the Dassault Systèmes 3DEXPERIENCE solution provides capabilities for each of these systems engineering needs with increasing levels of capabilities so companies can improve their systems engineering process over time while still having a unified approach. The following table summarizes the key systems engineering capabilities offered with 3DEXPERIENCE:

Capability

Requirements
Manager
(TRM)

Systems
Architect
(SAK)

Dynamic
Systems
Engineer (SNK)
and pre-requisites

Mechatronic
Systems
Engineer (SQK)
and pre-requisites

Multiscale
Systems
Specialist (MCK)
and pre-requisites

Requirements
and Test Case
Management

Functional and
Logical Sub-
System Definition

Systems
Behavioral
Modeling

Kinematic
Product Design

Orchestrate
Virtual
Simulation

We’ve all heard the buzzwords: digital transformation, product lifecycle, product data, PLM, PDM, systems engineering, models-based engineering and so on. It can be confusing, trying to figure out which technology or trend will have the biggest impact on the business. It’s also easy to imagine you’re missing out on a new, hot trend. But before we worry about whether we’re ahead of the curve or behind it, let’s be clear exactly what we’re talking about.

Defining Terms

Product Lifecycle Management (PLM) as a term has been around since the 1950s—it is not a new concept, but recently, more organizations are looking at this process as a place for improvement. A product lifecycle is simply the stages a product goes through from the initial concept to end of life—whether that’s a complex manufactured product like a rocket or a simpler product such as a house or a winter coat.

Product lifecycle management is the set of processes and/or procedures used to manage all of the product’s information throughout the lifecycle—from inception and planning; to design, engineering, and manufacture; to service and disposal.

At Adaptive, we have defined the product lifecycle to start with the digital design process and continues into the physical side of manufacturing for prototyping, testing, first article inspection, and quality control.

Is PDM also PLM?

But what about product data management (PDM)? Where does that fit?

As the words imply, PDM involves managing the information about a product, from models and drawings to bills of materials (BOMs) and more. But PDM shouldn’t be equated with PLM. PDM is about the data involved in managing all the data around the development of a product – product specifications, version control and more. PLM calls on the data in PDM to manage the entire digital design process.

Systems Engineering

Systems engineering is also sometimes confused with PLM, but that focuses on how to design and manage systems (which almost always include products). It’s the overall organization and oversight of a system, as well as the people and processes that ensure all aspects of a system are considered and integrated into a whole. PLM, which focuses on everything about the product, can sometimes help automate design processes related to systems engineering. But generally speaking, systems engineering has a broader scope, as it also includes the coordination of teams, logistics, and other responsibilities outside of the product stream.

Models-based Systems Engineering

Within systems engineering is the concept of models-based system engineering (MBSE). MBSE establishes a “model” to analyze and document key aspects of the systems engineering life cycle which includes system requirements, analysis, design, and validation and verification activities. Similar to a PLM, it is intended to improve communications within engineering teams and other stakeholders, it provides early identification of requirements issues, improves specification of allocated requirements to hardware and software resulting in fewer errors during integration and testing and provides requirements traceability, reduces project risks and lowers costs, and more.

Digital Transformation

The idea behind digital transformation is to establish a process for organizations to track the entire cross-functional cycle of product development capturing and integrating key data points to establish traceability and manage how a product is conceived, created, tested, and brought to market. In essence, the data trail creates a “digital thread” that captures the evolution of that product. Of course, this doesn’t happen all at once and needs to be taken in discrete steps that build success upon success. In some cases a digital thread will extend beyond the walls into the supply chain, this is the ultimate nirvana. However, many organizations are not quite ready for that just yet and it is more talk than anything. However, the concept of establishing a digital thread goes hand in hand with PLM and systems engineering strategies. The transformation part happens when there is a more collaborative approach in an organization when everyone is working off the same data and making better business decisions. We will be writing more on this topic later.

In Conclusion

As you can see, product development covers a broad spectrum in an enterprise as it tends to touch many functional departments as work gets completed across an organization. In some cases a business problem on the surface may not “appear” to be a PLM issue, but in many cases due to collaboration needs, managing product changes, and tracking all documentation it quickly becomes something a PLM strategy can affect.

Stay tuned for our next post where we will dive a little deeper into Understanding PLM Fundamentals…

Tag: Systems Engineering

Getting Started with Systems Engineering

Part 1: Understanding PLM, PDM, and More