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 🙂