Graph-Based Design Languages for Engineering Automation: A Formula Student Race Car Case Study

Abstract

The development of modern vehicles faces an increase in complexity, as well as a need for shorter development cycles and a seamless cross-domain integration. In order to meet these challenges, a graph-based design language which formalizes and automates engineering workflows is presented and applied in a design case study to a Formula Student race car suspension system. The proposed method uses an ontology-based vocabulary definition and executable model transformations to compile design knowledge into a central and consistent design graph. This graph enables the automatic generation of consistent 3D CAD models, domain-specific simulations and suspension kinematic analyses, replacing manual and error-prone tool and data handover processes. The design language captures both the structural and dynamic behavior of the suspension, supports variant exploration and allows for integrated validation, such as 3D collision detection. The study illustrates how graph-based design languages can serve as ‘digital DNA’ for knowledge-based product development, offering a scalable, reusable platform for engineering automation. This approach enhances the digital consistency of data, the digital continuity of processes and the digital interoperability of tools across all relevant engineering disciplines in order to support the validation of early-stage designs and the optimization of complex systems.

1. Introduction

Modern vehicle development is undergoing a profound transformation driven by increasing system complexity, shorter development cycles, and the growing need for cross-domain integration [1,2]. Traditional vehicle design processes, which rely heavily on isolated domain-specific tools and informal knowledge exchange, often result in fragmented models, inconsistent data flows, and time-consuming manual iterations [3]. These inefficiencies are particularly pronounced in the context of lightweight design, electrification, and aerodynamically optimized systems, where mechanical, thermal, and control aspects are deeply interlinked [4,5,6]. At the same time, advances in model-based design, systems engineering, and knowledge formalization offer new opportunities to rethink how engineering processes are structured and executed [7,8,9]. In particular, graph-based design languages provide a formal, executable framework that captures product knowledge, design logic, and process rules in a unified and reusable format [10]. Unlike conventional toolchains, which require engineers to translate information manually across domains, graph-based design languages enable automated generation of consistent CAD, simulation, and analysis models from a single, central source of truth [11].

The present paper introduces selected topics of a Formula Student race car design automation [12], based on a novel implementation of the design process using graph-based design languages. The shown methodology focuses on the suspension system of a Formula Student race car, using this as a simplified representative case study in the context of overall vehicle design. The proposed approach uses an ontology-driven vocabulary [13] and model transformations as design rules to encode structural, geometrical, and behavioral knowledge about the suspension system and the overall vehicle. The design language allows a unified representation of both topological and parametric properties of the design and incorporates, via model-transformations, a unique mechanism how the representation can be modified topologically and parametrically [10]. The design language is then compiled using a design compiler software platform to generate a central design graph consisting of all the product’s relevant design knowledge, including component relationships, physical properties and dynamic simulation results [14]. In this respect, design languages follow almost in a one-to-one mapping the concept of formal programming languages with a source code level (i.e., the design language), the object code level (i.e., the design graph), and the executable code level (i.e., the domain-specific languages) as inputs for all subsequent analysis tools. These modeling, simulation, and execution capabilities for the most relevant engineering disciplines, such as 3D CAD geometry generation, multi-body and finite-element simulation, as well as thermal analysis, and many more are a unique property of the used software platform DC43^® [15] and is, as such, subject of ongoing research and development, but not in the scope of the present paper.

The main scientific contribution of the present work lies therefore in demonstrating how graph-based design languages can transform the conventional vehicle design process into a knowledge-driven, automated workflow. In principle, this requires a complete methodological redesign of the formerly mostly manually driven vehicle design process into a new, purely digital and machine-executable process, using objects instantiated from background ontologies and design rules as model-to-model transformations to create an explicit digital model representation in form of a design graph, as an equivalent to the formerly implicit data structures created when using CAD, MBS, and FEM programs interactively [12]. Furthermore, it is not only necessary to model the product and its components, but also the logic of how the race car is synthesized, evaluated, and optimized. As such, a complete re-executable design process, in form of a language representation, which can be compiled and executed by a machine, has to be created. Hereby ensures the design language approach the digital consistency of data and models created thereof, the digital interoperability of the software tools, as well as the digital continuity throughout the development process [10]. As a further difference to other MBSE tools, which follow a visual modeling paradigm using standards such as SysML^® [16], design languages possess a string-based source representation, which is automatically mapped within the development environment DC43^® to the corresponding visual representations.

The remainder of this paper is structured as follows: Section 2 reviews current design processes and introduces the concept of graph-based design languages. Section 3 details the implementation of the method for modeling suspension systems. Section 4 presents the results in terms of the generated design graph, kinematic analyses, and variant exploration. Section 5 discusses the broader implications for vehicle design automation, followed by conclusions and outlook in Section 6.

2. Design Processes

Contemporary engineering design processes are often fragmented and rely on a multitude of isolated tools and models. This fragmentation leads to inefficiencies, inconsistencies, and increased error potential, especially as products become more complex and development cycles shorter. At the same time, advances in computational modeling and formal design methods offer new opportunities to rethink how engineering knowledge is captured and applied [17]. This section introduces graph-based design languages as a model-driven approach that formalizes design knowledge, automates model generation, and enables consistent, cross-domain engineering workflows.

2.1. Current Design Processes

In current engineering practice, product knowledge is typically distributed across various sources, ranging from technical documentation and industry standards to the personal experience of engineers and data from previous designs [18]. This fragmented knowledge landscape poses significant challenges in the context of complex, multidisciplinary product development [19]. To design a product, this knowledge must be translated into domain-specific models using specialized tools such as CAD (Computer-Aided Design), FEM (Finite Element Method), or CFD (Computational Fluid Dynamics) software [20,21,22,23], as shown in Figure 1. Each engineering discipline relies on its own toolchain, resulting in multiple, heterogeneous representations of the product across different domains [11].

These models are inherently interdependent, which means that they are dependent on each other for their existence and functionality. A change in one domain, for example a modification in the CAD geometry, often necessitates updates in other domains, such as structural analysis or thermal simulation [24]. Consequently, data must be exchanged and converted between tools frequently throughout the design process [25]. However, these data exchanges and model updates are largely manual, making them time-consuming and error-prone [26]. Each conversion step risks data loss, misinterpretation, or version mismatch, ultimately leading to inconsistencies between the domain models [27]. As product complexity increases, these inconsistencies can accumulate and severely impact the overall development process [28].

The fundamental problem here is the absence of a central product dataset or data model that captures all relevant design information consistently and coherently [29]. Without such a central model, engineering teams are forced to maintain multiple partial representations in parallel, an approach that is both inefficient and vulnerable to error propagation.

This observation motivates the need for a more integrated and automated approach to product modeling [30], as will be discussed in the following section.

2.2. Design Processes with Graph-Based Design Languages

The key for overcoming the challenges posed by fragmented tools and inconsistent models is not to manage complexity manually, but to avoid inconsistencies through a dedicated system information architecture [31]. This can be achieved by making use of a fundamentally different modeling approach that eliminates the need for repeated conversions between the domain-specific tools [32]. Instead of working with isolated models across different disciplines, the use of a central, holistic product model is proposed as the single source of truth. All domain-specific representations, such as 3D CAD geometry, 3D field simulations and further simulation parameters, can be consistently derived from this central model. This approach ensures the digital consistency of data and models, the digital continuity of processes, and the digital interoperability of software tools [10]. It also reduces the risk of manual errors across all domains.

A key question is how such a comprehensive model can be efficiently created and maintained. This is addressed by generating the model automatically, rather than relying on a manual design. In order to achieve this, the product knowledge must be captured in a format that is both computer-readable and executable [10,33]. This leads to the concept of a graph-based design language, a formal and executable modeling approach inspired by natural languages. In this framework, engineers describe the system architecture, components, parameters, and constraints using a defined vocabulary and explicit transformation rules. The design language is processed by a dedicated compiler, which instantiates an abstract design graph. This graph serves as the central representation of the system, capturing all relevant components, their interdependencies, and both functional and physical properties [11]. From this central design graph, the compiler automatically derives a unified, central product model, and all necessary domain-specific models (e.g., CAD, FEM, thermal simulations). This process is illustrated in Figure 2.

The use of a graph-based design language not only minimizes manual effort and error potential, but also establishes the foundation for advanced engineering automation, where models evolve together in a synchronized, rule-based manner. This compiler-driven approach shifts the engineer’s focus from model synchronization to the definition of reusable design knowledge, thereby enabling a high degree of automation and adaptability.

Building on this foundation, a graph-based design language can be understood as a formalized and executable representation of engineering knowledge. It captures not just the static structure of a product, but also the logic needed to synthesize and adapt it automatically. Such a design language typically consists of three core elements, a vocabulary, several rules and a production system:

• Vocabulary (in UML an instantiated object): A set of semantically typed elements that constitute the building blocks of the design language. Defined as an ontology, the vocabulary is typically formalized in a class diagram. These elements represent domain-relevant entities such as subsystems, components, and other granular entities. The classes in the diagram are enriched with properties that can represent, for instance, physical or cost variables.
• Rules (in UML model-to-model transformations): Transformation instructions, formulated in a simplified Java-based language, which define valid combinations, behaviors, and derivation logic between vocabulary elements.
• Production System (in UML an activity diagram): An executable orchestration of rules, visualized as an activity diagram, that controls how the design language is processed. It governs rule execution order, iteration, subprograms, and decision logic, producing the design graph from which domain-specific models are automatically derived.

These three core elements of the design language are created manually by the engineer, and collectively they form the basis for an automated product development process. Once the graph-based design language is defined, it can be executed automatically by a design compiler [11]. This compiler interprets the language and builds the design graph, which is the central, digital representation of the product.

The design graph serves as a holistic representation of the product that integrates all relevant aspects of the design in a consistent, structured way. From this central graph, all necessary domain-specific models, such as 3D CAD geometry, field simulations, or documentation can be derived automatically and consistently. The design graph thus becomes the single source of truth, ensuring coherence across disciplines and minimizing the need for manual transformation steps, as illustrated in Figure 3. However, the design process does not end with model generation. In engineering practice, especially for complex systems, design is inherently iterative. Therefore, the analysis of design graphs and domain-specific simulation results often indicates the need for modifications, refinements, or extensions. This feedback loop is directly supported by the design language. Engineers can refine the language itself, by extending the vocabulary, modifying rules, or integrating optimization algorithms.

The production system further supports advanced control structures such as loops, conditionals, and subprograms, conceptually inspired by UML activity diagrams, enabling the specification of more complex and flexible design generation logic. In this way, graph-based design languages not only automate model generation but also support continuous iteration and evolution, aligning well with modern engineering workflows that require both consistency and adaptability.

The terminology ‘design language’, ‘design compiler’, and ‘design graph’ reflects the terminology of high-level programming languages, where the (design) language represents the source code, the (design) compiler represents the translation machine, and the (design) graph stands for the intermediate object code, which is mapped by the compiler backend to the targets, in form of the domain-specific languages of the attached programs in Figure 3.

3. Formula Student Design Language Implementation

The following section describes how the suspension kinematics of the Formula Student race car is implemented using graph-based design languages. Modeling is carried out using the Design Cockpit 43^® (DC43^®) [15] software environment, which facilitates the structured definition, compilation, and execution of graph-based design languages.

3.1. Ontology and Class Diagram Modeling

Implementation begins with the creation of ontology-based class diagrams, which define the formal vocabulary of the design language. These diagrams represent the semantic background knowledge of the suspension system, capturing all the components, parameters and interdependencies required for kinematic analysis. The components of the actual race car suspension system are then created by instantiation and stored in the design graph for further processing.

3.1.1. Class Diagram $suspensionData$ Package

The $suspensionData$ package (Figure 4) defines the domain-specific ontology required to formally model the suspension subsystem of the Formula Student race car.

At the core of the model is the $Vehicle$ class, which acts as the top-level aggregation of all relevant subsystems including the $Chassis$, $Aerodynamics$, and both $frontSuspension$ and $rearSuspension$. It contains global vehicle parameters such as center of gravity, weight distribution, total mass, and wheelbase. These attributes are directly linked through physical relationships, expressed as equations, which support the consistent and automated derivation of key characteristics. The suspension itself is modelled using the $Suspension$ class, which is linked to all the main components required for a double-wishbone architecture. These components include the $Wishbone$, $Wheel$, $Damper$, $PushPullRod$, $Rocker$, $AntiRollBar$ and $TieRod$. Each component is defined as a subclass of $GeometricPart$, allowing spatial definition via 3D coordinate vectors and parametric control over geometry, stiffness, inertia, and other relevant physical properties [34].

Critical geometric parameters such as bearing diameters, wall thicknesses, and gluing dimensions are explicitly defined and linked via equations to ensure internal consistency. Subcomponents like $Wishbone$ and $PushPullRod$ include both analytical expressions (e.g., moments of inertia, stiffness calculations) and physical placement logic. In addition, aerodynamic and tire-related data are integrated through the $Aerodynamics$, $Tyre$, $Rim$, and $TyrePerformance$ classes. These classes enable analysis of the race car in the context of aerodynamic loads and tire dynamics, including force transmission, slip behavior and rolling resistance, all of which are crucial for lap time simulation [35,36]. Especially for determining tire performance based on test data, a dedicated artificial intelligence feature, recently developed in the publicly funded research project KIEZ4.0, based on symbolic regression [37], is used to extract a symbolic relationship between tire slip angle and lateral forces as a function of normal load. In this example, this feature allows a seamless adaptation of the lap time simulation to any tire type, for which such experimental data are available. In general, this artificial intelligence feature allows to deduce a symbolic expression for the functional relationship implicitly encoded by a set of given data points [37].

The interconnections between components are expressed using the $opposite$ keyword, which ensures bidirectional traceability and enables full graph traversal during execution. This means that each physical component is geometrically and semantically embedded within the system architecture, allowing for automated, rule-based instantiation and navigation within the design graph.

3.1.2. Class Diagram $suspensionStates$ Package

The $suspensionStates$ package (Figure 5) builds on the static definitions offered by the $suspensionData$ package, modeling the dynamic states of suspension components during vehicle operation. It captures the kinematic behavior of each suspension element, enabling detailed analysis of suspension characteristics and their impact on vehicle handling.

The steering linkage is represented by the $TieRodState$ class, which dynamically calculates tie rod length and angular displacement relative to the chassis. This allows for an accurate mapping of steering inputs to wheel steering angles and the evaluation of toe variation caused by suspension motion.

Similarly, the $DamperState$ class models the current displacement of the damper, providing essential information for simulating spring and damping forces under different suspension states [38]. Figure 6 illustrates the properties and the symbolic equations of the $DamperState$ class.

The solution path generator of the compiler solves these symbolic equations when executing the design language. This allows the declarative definition of the symbolic equations in the class diagrams, while the solution procedure is automatically computed internally by the graph algorithms of the solution path generator. To calculate the dynamic damper position on the rocker, the intersection of the spherical coordinates of the $PushPullRod$ fixed to the rocker and the $Rocker$’s two axis points are used. To find the correct intersection, the coordinate with the greatest z-direction value is chosen. The current damper compression is then calculated by subtracting the initial damper length from the current damper length. Due to this general form of modeling, the calculation of the dynamic damper state can be reused for different vehicle variants, without requiring additional modifications to the design language or the underlying computational modeling approach.

The anti-roll bar’s behavior is captured by the $AntiRollBarState$ class, which computes angular displacement and the resulting torque based on suspension roll angles, thereby quantifying the contribution of the anti-roll bar to vehicle roll stiffness and roll stiffness distribution. To gain a deeper understanding of the vehicle’s roll characteristics, the package includes calculations for the virtual instantaneous centers of the suspension and the roll center positions. These geometric constructions are derived from specific calculations of line-line and plane-axis intersections and provide an important understanding of the distribution of lateral and vertical suspension stiffness and its effect on vehicle handling [36].

Finally, the $SuspensionState$ class provides an integrative framework that combines the dynamic states of all individual components to create a full set of suspension characteristics.

3.1.3. Class Diagram $mathematicalOperations$ Package

The $mathematicalOperations$ package is used to perform all the necessary mathematical calculations involved in the modeling and analysis of the suspension kinematics. It performs essential geometric and algebraic operations, such as rotation transformations, intersection computations and distance measurements between all relevant components and coordinates. Figure 5 shows the connections between the $mathematicalOperations$ package and the other classes, as does the class diagram for the Formula Student race car example in Figure A1.

The $RotationMatrix$ class (Figure A2) is central to these operations, as it calculates the rotation of a point in three-dimensional space around an arbitrary axis by a specified angle. First, the class derives a normalized rotation axis vector from the two input vectors that define the axis line. It then uses the Rodrigues rotation formula [39,40] to construct a 3 × 3 rotation matrix, utilising trigonometric functions of the rotation angle. This matrix is then applied to transform the input point relative to the rotation axis, yielding the rotated point in global coordinates. Further classes address the problem of finding the intersection of three spheres, which is a common geometric operation in the analysis of suspension kinematics. These classes formulate the intersection condition as the set of points that are equidistant from three given centres, each with a specified radius [41]. Selection criteria such as minimizing the deviation in the x-coordinate from a reference point or maximizing the y- or z-coordinate of the solution ensure that the correct intersection point is chosen from among the multiple mathematical solutions. The $CalculateRadii$ class performs calculations for various important radii within the suspension system. These include the distances between essential components such as wishbone joints, tie rod connections, push- and pull-rods, rocker arms, dampers and anti-roll bars. These radii represent the fixed lengths of links that are essential for subsequent kinematic analyses. Finally, classes such as $IntersectionOf2Axes2D$ handle intersection calculations between lines and planes, as well as between two linear axes, in both two- and three-dimensional contexts.

Together, these classes form an extensive toolkit for addressing the geometric transformations and spatial intersection issues commonly faced in the design and analysis of various suspension systems.

3.2. Production System Definition

The next logical step is to define the vocabulary and implement a set of transformation rules and programs within the production system. This system governs the execution logic of all relevant rules and subprograms [10].

As shown in Figure 7, the execution logic within the production system (visualized as activity diagram) begins by loading predefined tire data and collecting user-defined simulation parameters via the $userInput$ rule. Key settings such as the suspension analysis type (e.g., vertical or steering kinematics), geometry generation and optional optimization steps are then configured and stored in the $SimulationSettings$ object.

The $initializeVehicle$ program then instantiates all the necessary vehicle components for further computation, as illustrated in more detail in Figure 7. This includes setting up general vehicle data, aerodynamics, the chassis, front and rear suspension, and tires. The program also performs consistency checks by removing unused tire and tire performance entries.

Depending on the chosen simulation type, the $suspensionStates$ rule triggers a specific state generation program for either vertical motion analysis, steering kinematics or a zero state by default. In all cases, this is followed by a connection process ($connectMath$), which establishes the links required for the subsequent mathematical computations. Finally, if geometry generation is enabled, the $geometry$ rule is executed. This involves a structured sequence of subprograms that are responsible for creating domain-specific representations of suspension components such as wishbones, uprights, dampers, tie rods, and anti-roll bars, to name the most important ones.

4. Results

After executing the underlying design language, the design graph is obtained as the final, comprehensive representation of the vehicle design. In this context, the design graph is a formal, interconnected model of the suspension system that combines structural, behavioural and computational information within a single data structure. It captures the physical configuration of the race car’s suspension components and the results of the kinematic analysis, forming the basis for subsequent design validation, evaluation, and optimization [34].

At the core of the design graph in Figure 8 are the instantiated representations of the vehicle’s various subsystems. These include the chassis, suspension, aerodynamics and drivetrain.

Each is modeled with relevant physical parameters, such as geometry, kinematics and system behavior. Associated performance data, such as tire characteristics or stiffness properties, is calculated and then stored in the nodes of the design graph. In addition to the properties of each class, the graph stores a complete set of calculation results specific to the suspension state. Dedicated instances contain the resulting positions, orientations and joint conditions of all relevant components for each defined motion state, such as steering or vertical movement. This enables the suspension system’s behaviour to be simulated accurately and quickly under varying vehicle configurations. The primary purpose of Figure 8 is its use as a machine-readable data structure to ensure data consistency across the design process. A human analysis of the design graph is only intended for interactive inspections and therefore depends on additional filtering options available in the design language development environment DC43^®. It should be clear that a human interpretation of such a data structure requires an in-depth knowledge of the ontologies from which the graph nodes together with their association and inheritance links are instantiated.

Furthermore, the design graph inherits procedural elements that perform the mathematical operations required for analysis, such as computing geometric intersections, axis-based transformations or projections. These functions are modelled in different classes, as explained in Section 3.1.3, and are directly linked to the component and state instances on which they operate. Consequently, all derived quantities, such as joint trajectories, collisions or motion limits, remain fully traceable and reproducible within the model. Beyond that, the design graph illustrated in Figure 8 serves as the central product model and the ‘single source of truth’ for the Formula Student race car. Within this holistic digital representation, nodes represent instantiated objects (building blocks) from the domain vocabulary, while edges denote multidisciplinary couplings and functional dependencies. The dense clusters visible in the graph reflect the complex system integration of the suspension, synthesized through automated model transformations.

As a consistent global data structure, the design graph enables the automatic derivation of various domain-specific models, such as parametric CAD or FEM simulations, ensuring multidisciplinary model consistency. In the design graph example shown in Figure 8, the central node in the visualized graph represents the vehicle instance and serves as the root element of the entire structural hierarchy. The dense clusters of connected nodes and edges to the left and right correspond to the front and rear axles, respectively. The stored data from the design graph is then processed further and used to visualize the kinematic characteristics of the racing car. Figure 9 shows a plot of the vehicle track depending on the vertical movement of the wheels for a given Formula Student vehicle.

The digital modeling framework used to compile and execute graph-based design languages also offers code-based geometry modeling. In this case, a boundary surface model (BREP) [42] is used for geometric representation. Alongside the abstract design of the vehicle, a corresponding 3D CAD model can be generated and exported in various formats [43]. In addition, components can be directly simulated during modeling through integrated thermal and finite element analysis [44,45]. Beyond single-model simulation, the digital framework enables the automated generation and optimization of multiple vehicle variants. These variants may differ not only in general geometry but also in their underlying topologies, such as the arrangement of suspension and damping systems. By systematically varying design parameters and topology configurations, the framework supports comparative analysis and design evaluation at an early stage of development. Figure 10 shows four automatically generated vehicle variants with different suspension layouts, based on the design of the Formula Student Team Weingarten [46], illustrating the impact of topology changes on the overall vehicle and suspension system design.

Since all results from the kinematic analysis are stored in the central design graph, they can be used directly to generate the vehicle geometry for all relevant states of motion. This allows for integrated, dynamic collision detection to verify the current race car design. To accomplish this, the boundary sourface model (BREP) is employed and then triangulated. Based on these triangles, it is determined whether two parts interpenetrate. Figure 11, for example, illustrates a detected interference between the inner wheel and the tie rod geometry during a steering maneuver. The affected components are automatically highlighted in a red color scheme to provide immediate visual feedback. In addition to visualization, collision information is persistently stored within the design graph and can be used in subsequent steps for automated validation and targeted design optimization.

In summary, the presented results demonstrate the capability of the graph-based design language approach to holistically model, analyze, and evaluate complex suspension systems within a single, unified framework. By integrating geometric modeling, kinematics simulation and topology variation, the approach enables automated early-stage design exploration and validation, as well as the detection of potential issues such as 3D component collisions. The design graph, which contains all the design knowledge, ensures the full traceability (both forward and backward, if need be) of computed properties and provides a consistent basis for subsequent processes, such as optimization of vehicle suspension kinematics or 3D CAD geometry generation.

Due to automation, the duration of the design process is reduced in principle to the execution time of the algorithms. In this application, one iteration of the Formula Student race car design takes about five minutes on an average PC, and includes suspension kinematics analysis, 3D geometry generation, and collision detection. As a consequence, a time reduction of a formerly manual design task taking several hours, to five minutes only, is achieved. In practice, this reduces the overall kinematic design process of a Formula Student race car from formerly several months to a time period of only two weeks [47].

5. Discussion

This case study demonstrates the effectiveness and advantages of using graph-based design languages to automate and integrate complex engineering tasks. Modeling the Formula Student suspension system within a formal, ontology-driven framework enabled the automatic generation of a design graph that consistently captures behavioral and parametric information across multiple engineering domains.

A key benefit of this approach lies in its ability to encapsulate design knowledge in a form that is both executable and reusable. Unlike traditional CAD- or script-based automation tools, the proposed method allows domain-specific logic, constraints, and structural rules to be expressed declaratively. This promotes greater transparency, traceability, and maintainability. Furthermore, compiler-driven execution ensures the consistent derivation of CAD models, simulation inputs, and design metrics, thereby eliminating the need for error-prone manual handovers between domain-specific software tools. The central design graph provides a unified representation of all relevant engineering data, supporting both forward synthesis and feedback-based refinement. This facilitates iterative design processes, such as adapting geometry based on collision detection or suspension characteristics. By integrating procedural rule sets and optimization algorithms into the same language environment, the approach enables advanced design space exploration and early validation of alternative topologies.

Analogous to DNA in biology, which encodes the complete blueprint of an organism [48], a graph-based design language can be understood as the ‘digital DNA’ of a company [49]— or, in this case, of a Formula Student race car [34]. This ‘digital DNA’ not only formalizes what is designed, but also how it is designed, offering a reproducible, evolvable, and scalable foundation for knowledge-based product development. Once established, such a design language becomes a strategic asset, enabling the reuse of design logic across vehicle generations and the continuous improvement of engineering workflows over several student generations. However, despite all these advantages, several important challenges remain, of which we mention the most important three.

The first challenge, the creation of ontology models and transformation rules, requires an additional initial invest of time and domain expertise, particularly in the case of multidisciplinary system design. Moreover, although the compiler ensures internal consistency, the quality of the generated models depends on the expressiveness and completeness of the physics encoded in the design language. Compared to the manual design process, where a single specific situation and its boundary conditions are in focus, the programming of the general, generic case, which covers a multitude of such situations with almost arbitrary boundary conditions, requires much more intellectual modeling effort and time. It is therefore clear that this extra effort represents an upfront investment which is only compensated for when the so called ‘break-even-point’ is reached later, after a certain number of automated program executions. However, since it is in generally agreed on that design is iterative by nature, it is very likely that any such ‘break-even-point’ will be reached either sooner or later.

The second challenge lies on the side of the user: abstract thinking, generic modeling, and a compile step between the source code representation and the resulting models require unfamiliar levels of abstraction, which mechanical engineers are typically neither used to nor educated for. This might hinder an immediate and widespread acceptance of the graph-based design language approach at present and limits it currently to these audiences, which do not experience this as an obstacle. Similarly, the third challenge also lies on the side of the user: object-oriented analysis (OOA), and object-oriented programming (OOP) skills are the new ingredients for success in engineering automation. If not already present, this has to be adequately reflected in future university curricula, which need to include such basics of computer science in their engineering education.

Beyond this need for an initial invest, the case study shows that graph-based design languages provide a robust and scalable approach to managing design complexity, are capable to push automation to a new level and to reduce development time at the same time, thus enabling a machine-readable and machine-executable knowledge-based product development and innovative knowledge management.

As an outlook in view of future-oriented applications of graph-based design languages, the externalized data model in form of the design graph allows for the straightforward integration of several AI-techniques into the shown methodology. Most notably, an integration of Large Language Models (LLMs) using the design graph as input for retrieval augmented generation (RAG) techniques to further improve the answer precision when using the LLM for a complex graph query [47]. Furthermore, as it is straightforward to loop around a fully executable code sequence for optimization purposes, the design language can be embedded in an optimizer, such as particle multi-swarm optimization (PMSO), which has been explicitly chosen due to the unavailability of gradient information (such as collision detection or FEM simulation results) encoded in external process chains [34]. Finally, to mention, the future prospects of graph-based design languages for an improved knowledge management based on the ‘design-as-code’ paradigm and supported by the integrated design language version management in the Git-source repository [47].

6. Conclusions

This paper has presented a graph-based design language approach for automating and integrating complex engineering workflows, demonstrated through a case study of a Formula Student race car suspension system design. By formalizing product knowledge within a structured ontology and compiling it into a central design graph, the method enables consistent generation of CAD models, simulation inputs, and design metrics across multiple domains. The results show that this approach significantly reduces manual modeling effort, enables full forward and backward traceability, and supports iterative, knowledge-based development processes. The concept of a graph-based design language as the ‘digital DNA’ of an engineering organization highlights its potential as a reusable and evolvable foundation for design logic, methodology, and domain integration. Looking to the future, this methodology offers a scalable route towards further engineering automation, variant-driven development and early-stage design optimization based on formal languages and associated language compiler technologies.