System Engineering

System Eng FAQ V1.1 System Engineering is for me one of the most interesting domain to explore in PLM side if it is really integrated in the PLM. Perhaps because this process is very closed to the process used today in order to deliver a proper PLM solution from my side 🙂

Today defining a product become complex because it is involving different domains: mechanical engineering, electrical, fluids, software… all those components interact together in order to deliver a complete product. This product is mainly defined at the beginning via global requirements, those requirements musts be covered, track and managed during the whole design process. What is the challenge exactly?

    1. Requirements management: Being able to track all requirements in a single source and linked to others definitions covering those requirements. It seems to be simple when I say that, but in reality it is not so simple. Mainly if we consider requirements as an alive package: I mean requirements are sometimes contractual, sometimes coming from marketing side… anyway, those requirement are extended, reduced or changed during the project time-frame. This management can become complex for product definition as every changes can have an impact on the definition on every domains. Today PLM solutions integrate mainly requirements tracking but not really on requirements management as yo can managed them in systems like DOORS (IBM) or Integrity (PTC) for software engineering. So today PLM can cover the link between a requirements baseline and a product definition with RequirementLink (PTC), Enovia Requirement Central/Reqtify (DS) or TcSE (Siemens), and it is a good start 🙂
    2. Functional description: This step, BOM or tree is very interesting in order to link requirements to functions but also giving the abstraction of the final product in terms of covered functions and analysis. Simulation can start here!! Even if the logical component will be mechanical, electrical, soft etc… all of those components are defined in terms of functions covering validated requirements. Some frameworks and tools are dedicated today to the definition of those components or can be described as functional requirements.
    3. System or logical description: this is the most growing part today in product definition. By defining systems covering part of functions and integrate them together even if they are electrical systems, software or  what ever … they have to cover functions. Those systems are designed in terms of functions/inputs/outputs and linked to the others via interface. Mainly specialized tools are able to design and sometimes simulate the system but most of time for a single domain. A real integration of those design tools with the PLM could covering a global definition of the product and why not simulate the entire product… The dream 🙂
    4.   The last part is the most common by designing physical elements as we use to do via CAD tools and integrate them in the PLM.

Today all those concepts are well known but not really integrated. Most of time requirements, functions and Systems are managed in various specialized products or home made integrated or not to PLM. PLM covers mainly physical design linked to functional requirements but some interesting initiatives are coming:

A rich and quite young domain integration in PLM and really exiting to discover and build 🙂



Commercial Off-The-Shelf is a generic product created by PLM vendors in order replace in-house products. Motivations for using COTS components include hopes for reduction of overall system-development and costs and reduced long-term maintenance costs. The idea is to be more and more closed to the COTS and covering specific business needs 🙂 So we have a lot of work…


Out Of The Box, explains capabilities of a product when you buy it. It means capabilities of a product without any customization.


Luc Boucher - PLM Expert - PLM FAQ Product Lifecycle Management is quite difficult to scope, as it’s name could cover everything around a product. At the beginning PLM was called PDM (Product Data Management) as it was a solution to manage technical data of the product mainly focused on engineering ( through CAD integration) and a little bit on manufacturing side. When PDM was more « collaborative » (ie. more user friendly for non engineering guys, and more open for collaboration) we have seen a lot of names for PDM (cPDM,xPDM,..) means that PDM needs a new name in order to integrate new services and areas. PLM was born in order to explain a new generation of PDM for the extended enterprise and a larger functional scope.



Today PLM services are mainly (mandatory 😉 ) :

  • BOM management : description of the product as a parts’ tree
  • Configuration management : Describing the exact BOM for a specific product and sharing BOM across product family to increase re-usability
  • CAD integration : Capability to manage CAD files from the PLM and defining BOM related to them with business rules integration
  • Multi-BOM management : Capability to define a product BOM regarding business needs : engineering, manufacturing, support etc.. linked together
  • Documentation management : Ability to manage documents linked to the product BOM
  • Digital Mock- up : light management and visualization of CAD assembly
  • Process Management : Managing changes on product definition

A lot of new services are today available but not covered by all solutions :

  • System Engineering : Product decomposition : Requirements, Functional, Logical, Physical
  • Multi-CAD : Capability to manage a CAD assembly done by various CAD tools
  • BOM Documentation management : Ability to manage a documentation BOM and is configuration close to the product BOM
  • Simulation Management : Simulation integration in order to use CAD models and/or BOM information to simulate product on situation
  • Documentation publishing : Generate product documentation in various format regarding product configuration management
  • Software configuration management : integration of SCM linked to product BOM
  • Manufacturing process definition and linked to the Engineering BOM
  • Extended enterprise : Capability to share and offering services to partners with a strong security management on the BOM
  • Project and Program management
  • Reports management : extracting information mainly for quality, regulation, exchanges purposes

PLM still today more data oriented than process oriented, the main goal is to manage product data truth and exchange it during the product lifecycle. Process are mainly covered today by other solutions like ERP, MRO.. Most of giant PLM vendors are trying to integrate process solutions inside PLM, but the better way could be : becoming the best in class on the PLM scope today first 🙂