With P4-DevOps, we address two major challenges in product development:
- Proving process compliance with all relevant process standards and legal regulations. To achieve this, process standards must be mapped to the development process (traceability), and documents must be created and archived during product development to serve as evidence.
- The effective integration of “generative AI” into the development process to improve, automate, and accelerate product development. To achieve this, the development process and its artifacts must be fully digitized.
We address the first point in P4 with the introduction of P4-DevOps Multiple Process Conformity (MPC) through Conformity Mapping. We have deliberately chosen open, non-binary data formats, such as JSON, YAML, and Markdown, so that your data remains yours and you can use it as you see fit (no vendor lock-in). Furthermore, this allows all documents and data elements to be stored in Git repositories and versioned, compared (diff), and merged just like software code. We call this ProcessAsCode.
The ProcessAsCode approach also helps us address the second challenge: AI systems (LLMs) are exceptionally good at understanding plain-text documents and generating them with high quality and precision (for small, well-defined tasks and with appropriate prompts). As a result, text-based data and programming languages are currently the preferred domain for LLMs. In P4, we therefore use non-binary data formats not only for process descriptions and product documents, but also to describe the product and its constraining and descriptive rules. For this purpose, P4 uses the system description language SysML v2 from the field of Model-Based Systems Engineering (MBSE). In our view, this is an ideal complement!
The key to acceleration and automation lies in the use of the P4 process model (P4-Activity Workflow), which is based on Knowledge-based Product Development, KBPD. In addition to a clear iterative-incremental process model for gaining knowledge and insights, P4 has introduced the concept of Knowledge Gaps (aka K-Gaps) as a central driver for this. This ensures that the solution space is first sufficiently expanded (divergent exploration, set-based concurrent engineering) and only then narrowed down to one or a few design options in accordance with the Constraints and Quality Attributes (convergence).
The generation of design options (also known as System-Concepts) is fed by the following data sources:
- external, publicly accessible databases containing design principles, design proposals from component manufacturers, material data, manufacturing technologies, etc.
- purchased data sources containing material properties, data on the service life and aging of components and materials, simulation data, and tools.
- Internal data from previous product developments, as well as results from simulations and experiments. It is precisely this data that constitutes the company’s wealth of experience and ensures its competitive edge over rivals. To this end, this data must be stored in a reusable format, rather than remaining solely in the minds of the engineers.
Side note: Human weaknesses that pose obstacles in product development:
- People hoard knowledge to feel good about themselves (“I know better”) and to feel secure (“I’m irreplaceable”). When an employee leaves the company, her wealth of experience is lost along with her.
- People have limited memory (compared to computers). The complexity of today’s product development makes it impossible for a single engineer to know “everything.”
- We are all problem solvers. People like to think in terms of solutions and narrow down the range of possible solutions too early, often without fully understanding the problem.
- People want to be creative, not document. Documenting is usually perceived as a burden and an obstacle, and is therefore often put off until “later.” But “later” doesn’t make it better—it makes it worse.
AI-driven support or full automation helps with all of the points mentioned.
The Vision: Fully Automated System Development
When examining the P4 workflow, it becomes clear that it is well-suited not only for human processing but also for AI agents. The idea here is that the agents, guided by their prompts and execution rules, are also given the constraints dictated by regulatory requirements or specified system properties (e.g., cost, mass, exclusions of materials and manufacturing processes). In addition, the Knowledge Gaps and their Risk Impact help determine the sequence of simulations, analyses, and their evaluations. This allows for faster decisions on whether the design options under consideration should be discarded or further optimized. As a welcome “side effect,” AI agents immediately generate the required documentation (based on P4 templates), thereby ensuring traceability and clarity while populating our Knowledge Base.
The Process
- People define the product vision, target markets, and users.
- People define the constraints.
- The Requirement Agent translates stakeholder needs into system requirements.
- The Design Agent generates multiple solution options (system concepts), including breaking them down into modules and interfaces. To do this, it draws on external knowledge (the Internet, databases) and internal knowledge from the knowledge base.
- The Risk Agent evaluates the solution options, creates a list of knowledge gaps, and prioritizes them based on their risk impact.
- Specialized Tool Agents perform simulations to close the knowledge gaps.
- The Design and Risk Agents evaluate the results against the constraints and decide whether to reject or refine them.
- The best solution options are presented to humans for a decision.
- The designed architecture of modules and interfaces is now optimized module by module. Additional “system loops” may be necessary if the module optimizations are not successful.
Challenges
- The prerequisite for an automated process is a clear and unambiguous description of the functions and constraints (item 2 in the list above). The constraints are divided into “hard” constraints (mandatory elements, capabilities, and properties; exclusions, and limits) and “soft” quality attributes (non-functional requirements, NFRs), which must be balanced or optimized according to specifications. These include manufacturing costs, material costs, weight, robustness, durability, repairability, and energy efficiency. To describe these rules, P4 uses SysML v2, which can be represented both graphically and in text form. The real challenge, however, lies in the product owner committing to a specific set of rules, although ranges are advantageous and feasible, especially at the beginning of the system design. It is important that the necessary priorities or weights are defined for Step 7 in order to evaluate solution options against one another.
- To generate the solution options in Step 4, the design agent requires comprehensive access to reference designs and their properties. Typically, the internal knowledge base is not yet sufficiently populated at the beginning.
- Step 6 requires appropriate simulations or other analysis tools. For example, the dynamic system behavior can be modeled by simulating finite-state machines (FSMs). Of course, once the design reaches a certain level of maturity, building and testing prototypes becomes necessary, which slows down the design loop.
Module optimization
To optimize solution options at the module level, additional modern techniques can be employed, such as the Logic-based Computational Engineering Model (LCEM) for module design, simulation, evaluation of results, and the rejection or improvement of options. Furthermore, the use of generative manufacturing methods enables new, fractal designs that resemble naturally occurring structures. A good example of this is the rocket engine from Leap71. Analog chip designs are also conceivable, for example, where the chip compiler can calculate, simulate, and optimize all properties of the semiconductor.