Unveiling Myths in System Engineering, MBSE, PLE, PLM, ALM & Product Development Realities

Myth 1: Systems Engineering is just Documentation

Systems engineering is an interdisciplinary approach that focuses on designing, integrating, and managing complex systems throughout their lifecycle.

Traditionally, systems enginering has been document-based, which may give the impression that it is merely about creating documents. However, it encompasses much more as shown in the above V-Model Product Development.

Myth 2: Systems Engineering is only for Engineers

The misconception arises from the term 'Engineering' in its name, which is due to its origins and strong connection to engineering principles and practices.

Systems engineering involves professionals from different disciplines to ensure that all aspects of a system are considered and integrated effectively.

For e.g. the following non-engineering roles are involved in system engineering

(1) Business analysts to understand, analyze and document the needs and expectations of stakeholders

(2) Market and Financial Analysis to assess market demands, financial viability, and business impacts

(3) UX/UI design team to understanding how users interact with systems

Myth 3: Systems Engineering is only for Large, Complex Projects

While systems engineering is essential for large and complex projects, it is also valuable for smaller projects. The principles of systems engineering can improve project outcomes by ensuring that all aspects of the system are considered and integrated effectively, regardless of the type and size of the projects and products.

Myth 4: MBSE replaces Traditional Systems Engineering

With the increasing complexity of today's products and the evolution of technologies, there is a shift from document-based methods to model-based approaches, which might suggest that MBSE replaces traditional systems engineering. However, this is not the case.

MBSE (Model-Based Systems Engineering) complements rather than replaces traditional systems engineering. It offers a structured approach to using models to enhance communication, understanding, and decision-making, while still relying on fundamental systems engineering principles..

Myth 5: MBSE is only about creating Diagrams

While visual models and diagrams are a significant part of MBSE, the approach is much broader. It involves creating, managing, and using models to analyze, specify, design, verify, and validate systems throughout their lifecycle.

MBSE is a comprehensive approach to systems engineering that emphasizes the use of models throughout the lifecycle of a system. It integrates various models to provide a holistic representation of the system, including functional, physical, and behavioral aspects.

Myth 6: PLE is only about reuse and only for Configurable Products

The term "product line" itself suggests a focus on a series of similar products with shared components, which naturally leads to an emphasis on reuse and configurability but PLE encompasses much more than just reuse.

Product Line Engineering (PLE) is an interdisciplinary concept. When PLE is implemented to its full potential, it has far-reaching effects that transcend the entire company, influencing every department and operation. For e.g.

• SALES team can leverage PLE to better understand and anticipate customer needs by providing a clear view of the product variants and features available. With PLE, the sales team can quickly adapt to market changes by offering the right product variants that meet evolving customer demands.
• MARKETING can leverage the insights from PLE to create more targeted and effective marketing campaigns, focusing on specific features and benefits that resonate with different customer segments.
• PRODUCT Management team uses PLE as a strategic framework for managing the entire product portfolio.

As shown above, in Product Line Engineering (PLE), the term "product" encompasses more than just the primary entity being built and delivered. It also includes all associated assets that are produced throughout the development process. These assets can be broadly categorized into two types: those that support the engineering process [project plans, requirements, specifications, system models, test plans/ cases, etc] and those that are delivered alongside the main product [parts, labels, manuals, etc].

Myth 7: SysML is just UML with a few extras

The misconception may be because SysML is derived from UML and has similar diagrammatic notations. UML is primarily design for software engineering where as SysML is tailored to model complex systems beyond just software. SysML models a broader range of systems that can include hardware, software, data, processes, personnel, and facilities.

SysML 1 was developed as a profile of UML, meaning it extended and customized UML for systems engineering purposes. SysML 2 uses KerML as its foundation to define its metamodel. The semantics and structure of SysML 2 are built on KerML concepts

Myth 8: SysML is only useful during the Design Phase

Due to the strong focus on modeling and design aspects, many people belief that SysML is only for design phase. However, SysML is actually applicable throughout the entire system lifecycle, from requirements definition and analysis to design, verification, validation, and maintenance.

(1) Requirements Engineering - SysML includes requirement diagrams to capture, manage, and trace requirements throughout the lifecycle

(2) Analysis and Specification - SysML supports behavioral modeling which helps in understanding and specifying system behavior before design begins

(3) Design and Architecture - SysML provides detailed views of system components and their interactions.

(4) Verification and Validation - Parametric diagrams in SysML support performance and constraints analysis, which are crucial for verifying that the system meets its specified requirements

(5) Maintenance and Evolution - SysML models can be used to manage and track changes to the system throughout its lifecycle, supporting ongoing maintenance and evolution

Myth 9: The V-Model is only suitable for Waterfall Development

The perception that the V-Model is only suitable for Waterfall development arises from its origins and traditional linear representation. However, with adaptations for iteration and flexibility, the V-Model can be applied to modern software development practices, including Agile.

When the V-Model is applied to Agile-based development, each sprint becomes a mini V-Model in itself. Agile methods use story maps, which include epics, themes, features, and user stories, for logical decomposition, aligning with the left side of the V and the Continuous Integration, Continuous Testing, and Continuous Delivery, which are core Agile practices, map effectively to the right side of the V.

Myth 10: ALM is only for Software Development

The misconception that ALM is only for software development stems from its origins and predominant use in the software industry.

ALM refers to the process of managing the entire lifecycle of an application from initial planning and development to deployment, maintenance, and eventual retirement. The term "application" in ALM refers to various types of software systems & solutions like Custom Software, COTS, Web Applications, Mobile Apps, Enterprise Application, Embedded Systems.

In industries like automotive, aerospace, and healthcare, ALM principles are used for the design and development and rollout of embedded systems that combine hardware and software components. ALM tools and practices support PLM processes as well.

With respect to PLM, ALM is primarily for intangible assets where as PLM is primarily for tangible assets.

Myth 11: ALM for 'Software in a Product' is the same as for 'Standalone Software'

ALM for software embedded in a product involves unique challenges, such as hardware dependencies, real-time performance requirements, and regulatory compliance. It integrates with product lifecycle management (PLM) systems to manage hardware-software interfaces, version control, and field updates.

Myth 12: Digital Twin is just a 3D CAD Model

The best analogy to explain this misconception is to compare it to the common belief that robots should look like humans. Just as robots don't have to resemble humans in appearance, a digital twin is much more than just a 3D CAD model.

Marketing materials and media coverage frequently highlight the 3D aspects of digital twins because they are visually appealing and easier to grasp for a general audience. Also, early digital twin implementations often focused heavily on 3D models to simulate physical assets, reinforcing the idea that a digital twin is primarily about visual representation.

A Digital Twin is just the digital counterpart of a physical asset, focusing on specific aspects such as performance, operational conditions, and maintenance requirements. It does not replicate every physical detail but captures relevant data and attributes necessary for analysis, simulation, and decision-making. This broader scope is what differentiates a digital twin from a simple 3D representation.

For e.g. the following digital twins can be implemented without necessarily requiring a 3D representation:

(1) Healthcare - Patient Health Monitoring

(2) Energy Mgmt - Smart Grids

(3) Supply Chain Mgmt. - Simulating and optimizing logistics networks

(4) Telecommunications - Network Performance Monitoring

Myth 13: PLM is just a Software Tool

PLM is a comprehensive approach that integrates people, processes, business systems, and information. While PLM software is a critical component, it also involves strategies, methodologies, and best practices for managing the product lifecycle.

Myth 14: PLM is only about managing CAD files

People associate PLM (Product Lifecycle Management) primarily with CAD (Computer-Aided Design) files because of the historical development and early implementations of PLM systems.

(1) PLM systems originally evolved from Product Data Management (PDM) systems, which were heavily focused on managing CAD files and related engineering data.

(2) PLM systems were first adopted by engineering departments, where the primary data types were CAD models and drawings.

Myth 15: CAD automatically generates a complete and accurate BOM

The MCAD (Mechanical Computer-Aided Design) structure primarily represents the 3D geometric and spatial relationships of components. CAD is a content.

In contrast, the BOM (Bill of Materials) details the parts, materials, and quantities required for manufacturing, including non-mechanical parts such as electrical, electronic, chemical, and consumable items that are not part of the CAD structure. The CAD structure and BOM complement each other but are not interchangeable

Myth 16: ASPICE is only applicable to Software Development

It is obvious from the name as ASPICE stands for 'Automotive Software Process Improvement and Capability Determination' but in reality, its scope goes beyond just software development and includes various aspects of system and hardware engineering.

ASPICE is a process assessment model designed to evaluate and improve the development processes of embedded systems in the automotive industry.