<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=5292226&amp;fmt=gif">
Skip to content
All Posts

How it works: SPREAD's Engineering Tech

by SPREAD Team on

At SPREAD, our mission is to make product data accessible, intuitive, and actionable for engineering teams, empowering them to lead the next era of software-defined product innovations through creativity and Agentic Engineering Intelligence.

“Agentic Engineering Intelligence” in 3 steps

'Garbage in, garbage out' isn't just a saying - it's a fundamental truth. Valuable (Gen)AI applications can only exist in manufacturing industries when built on a strong and consistent data foundation - structured and unstructured product data which is integrated across various systems and tools to give engineers a holistic understanding.

We enable engineers to gain deep insights into their products and make data-driven decisions throughout the product lifecycle by leveraging technologies like a knowledge graph, schema, graph federation, machine learning, AI agents, GraphQL, and a multi-tenant cloud architecture.

Our end-to-end solution is built on an architecture that ensures flexibility & scalability, security and powerful data integration for our entire Engineering Intelligence solution suite. On top, it offers multiple ways of integration into your existing infrastructure.

Our Engineering Intelligence platform works with 3 steps:

  1. Rapid Data Ingestion
  2. Product Twin empowered by the Engineering Intelligence Graph
  3. Action Cloud with Agentic Engineering Intelligence

The following article provides a detailed overview of these steps (1-3) and further foundations of our platform (4).

Blog_1920_1

1 Rapid Data Ingestion

First step: At the foundation of SPREAD’s architecture is the Data Ingestion & Mapping layer, which integrates diverse data sources via out-of-the-box Smart Connectors for specific data formats (such as spreadsheets, databases, 3D formats, CAD formats), a configurable Generic Mapper and a Data Sourcing Layer. These harmonize both structured and unstructured data into a knowledge graph called SPREAD’s Engineering Intelligence Graph creating a comprehensive, centralized database.

Efficient data ingestion and mapping are key to integrating diverse data sources:

  • Files, systems, experts, API calls: Data from various origins, such as system databases, expert inputs, and API calls, are brought into a unified ecosystem.
  • DB, services, streams: Supports databases, web services, and real-time data streams, allowing SPREAD to handle a wide variety of data types.
  • Declarative mapping: Simplifies data mapping by translating diverse data formats into our cloud environment.
  • Systems data provenance: Ensures reliability by tracking the origin and history of data.
  • Quality gate: Maintains data quality by ensuring that only high-integrity data enters the system.

1.1 Out-of-the-box Smart Connectors


Connectors are the bridges that link various data sources to the knowledge graph. They ensure seamless data flow from different systems and tools into our graph. For instance, a connector might pull design data from a CAD system and PLM engineering systems, feeding both into the graph for a unified view.

PLM systems are integral to managing this data. However, without proper integration into a broader data ecosystem, even the best PLM tools fall short in delivering the visibility needed for today’s fast-paced vehicle projects.

By offering pre-configured connectors to these systems, SPREAD eliminates the barriers to integrating crucial PLM data with other engineering and enterprise systems. It aggregates this data automatically, ensuring accurate, synchronized insights into product maturity and development progress.

Integrating PLM systems with SPREAD brings several key advantages:

  • Source integration: Connectors integrate data from CAD systems, PLM systems, ERP systems, system databases, and more.
  • Data normalization: They normalize data into a common format, making it compatible with our schema.
  • Real-time syncing: Connectors can sync data in real-time, ensuring that the graph always has the most up-to-date information.
  • Unified product view: Data from multiple sources — PLM, ERP, and custom engineering databases — is unified into a single, accessible dashboard.
  • Reduced integration costs and complexity: The out-of-the-box connectors are designed for quick deployment, allowing teams to benefit from seamless integrations without the need for significant technical resources.

1.2 Data Source Connecting Layer


The data source connecting layer is a middleware layer that facilitates the connection and integration of multiple data sources into a unified system. This layer acts as an intermediary between the data sources and the target system, ensuring that data from disparate origins can be aggregated, harmonized, and made accessible for analysis and processing. It typically handles tasks such as data extraction, transformation, loading (ETL), and data synchronization.

1.3 Generic Mapper


The Generic Mapper translates data from one format or structure to another. In the context of the knowledge graph, it allows data from various sources, such as PLM systems, ERP systems, or IoT devices, to be harmonized with our schema and imported to be accessible by the knowledge graph. This uniquely powerful harmonization process is crucial for enabling seamless data interoperability and analysis across different systems and domains. In detail, harmonization in this context means understanding and transforming complex hierarchical source data formats into the schema of the knowledge graph - a capability that sets our solution apart from other mapping approaches.

1.4 AI-assisted Mapping


AI-assisted mapping involves using artificial intelligence to co-pilot and thus enhance the process of mapping data from various sources to a unified data model. This can include identifying and matching data entities, detecting patterns, and making recommendations for data transformations. In the context of Engineering Intelligence, AI-assisted mapping helps in efficiently integrating large volumes of complex data by reducing the manual effort required and improving the accuracy and consistency of the data mapping process.

This layer supports data ingestion and transformation from CAD, PLM, ERP, and IoT sources, enabling seamless data integration with SPREAD’s Engineering Intelligence Graph. It lays the groundwork for SPREAD’s AI-driven ecosystem, ensuring that all data is ready to fuel the Product Twin.

2 Product Twin powered by the Engineering Intelligence Graph


The second step and the heart of SPREAD’s stack is the Product Twin. This is a sophisticated, dynamic digital representation of each product that captures and contextualizes data across the product lifecycle. The Engineering Intelligence Graph serves as the backbone of the Product Twin, organizing and interconnecting structured and unstructured data—such as component specifications, error reports, release plans—into a cohesive, actionable model.

2.1 Product Twin


The Product Twin consists of two critical layers:

  • Engineering Intelligence Graph: Our federated supergraph is the core of our solution and unifies domain- and task specific subgraphs into one uniform API. The subgraphs can be optimized for the data they serve and the problems they solve without adding complexity to the applications consuming the data.
  • Schema: Our schema, also known as the Information Model, is the glue between the domains and their data. It defines the meaning of entities and their context in terms of attributes and relationships. This results into our ever-evolving Engineering Intelligence Graph. Automated processes guarantee the integrity of your data, ensuring that engineers have a single source of truth for all product-related data.

By mapping intricate relationships across components, lifecycles, and engineering domains, the Product Twin simplifies complex analyses and enhances decision-making. SPREAD’s Product Twin provides engineers with a holistic view of dependencies and system functionality, making it a powerful foundation for all Engineering Intelligence solutions.

The following section will take a detailed look at the fundamental concepts underlying the Product Twin.

Blog_1920_2

2.2 Engineering Intelligence Graph

The Engineering Intelligence Graph (a knowledge graph for Engineering) is our backbone, that interlinks and stores structured product data and relationships. It is a GraphQL-based system, that uses graph structures with nodes, edges and properties to represent and store the data.

Think of it like this: complex mechatronic systems have become so interconnected that humans can no longer understand and manage the systems on their own. In the best case, a graph-like representation of mechatronics systems could also be found in siloed systems of an R&D department, but the data usually does not follow a schema, the schema is not documented, or it is not defined in a manufacturer- or product-agnostic way. Moreover, the data is not linked to related data in other corporate systems. This forces practitioners to manually cross-reference exports of this data, which is not a maintainable way.

Our Engineering Intelligence Graph solves this problem with the schema and its two core layers:

  • The information layer is an evolving data schema combining multiple contexts (R&D, Production, Aftermarket, etc.) into one system with interrelationships. Our schema is proprietary, and the heart of our Engineering Intelligence IP built over the last 5 years.
  • The data layer is comprised of all the instances of data following the schema in our system. It can be thought of as a network of predefined objects over all domains hosting all product-related data in canonical representation – our single source of truth for all downstream applications.

The Engineering Intelligence Graph allows for a holistic view of complex systems across the whole product lifecycle and across all domains. This enables better decision-making and more efficient problem-solving. It further empowers technologies like (Gen)AI by providing the necessary knowledge and ground truth to understand system functionality. This boosts AI efficiency and performance, driving greater productivity, quality, and faster product innovation.

2.3 Schema

A schema, also known as the Information Model, is essentially the blueprint for organizing and structuring data within the Engineering Intelligence Graph. Here’s a closer look at its role:

  • Structure definition: The schema defines entities (e.g., components of a vehicle) and their attributes (e.g., engine specifications, software versions).
  • Relationship mapping: It maps how these entities relate to each other (e.g., how the engine connects to the transmission system).
  • Integration foundation: By providing a common structure, the schema ensures that disparate data from various sources can be integrated seamlessly.

For example, in an automotive context, our schema defines relationships between CAD design elements, features, variants, cable, or hardware, ensuring they all fit together cohesively within the graph. This makes synergies in data manifest and enables to easily build dashboards or other applications on top of it. For it to scale, we have a lot of mechanism in place to derive service implementations, application maintenance and data migrations from the content of the schema itself.

Blog_1920_3

2.4 Graph technology

A graph is a formal structure used to represent relationships between entities. It consists of two main components: nodes and edges. Nodes represent entities, while edges represent the relationships or connections between these entities.

This structure is incredibly versatile and can model various scenarios, such as social networks or mechatronic systems. For instance, in mechatronic system, nodes can represent ECUs and software, while edges can model all feature dependencies. The power of graphs lies in their ability to visually and structurally map out complex, interconnected and interdependent systems, making it easier to analyze and understand the underlying relationships and patterns.

2.5 Graph database

A graph database is a type of database management system designed to store, manage, and query graph-structured data. Unlike traditional relational databases that use tables and rows, graph databases use nodes and edges and properties on either of them to represent, store, and link data.

These databases excel at handling data with complex relationships, as they inherently model the connections between data points. They are optimized for tasks involving extensive data traversal and complex relationship queries. Graph technology plays a crucial role in managing highly complex mechatronic systems by providing a robust framework for representing, analyzing, and optimizing the intricate relationships and interactions within these systems. Such as, components of a car’s wiring harness, their connection via cables down to pins of connectors of the components and their connection via single wire strands of cables.

2.6 Supergraph and federated subgraphs

Subgraphs and supergraphs are integral concepts in scaling graph systems that help to manage and analyze complex datasets. A subgraph is a subset of a larger graph (supergraph). Subgraphs are typically used to represent and manage specific domains or areas of interest within the broader dataset.

The supergraph, on the other hand, is the overarching graph that contains all the subgraphs. It provides unified querying capabilities to the entire system, integrating data from various subgraphs. This integration allows for holistic analysis and insights across different domains. The relationships and data within subgraphs are often interconnected, enabling the supergraph to facilitate cross-domain queries and analyses. The supergraph and all its federated subgraphs together form the Engineering Intelligence Graph.

For instance, a comprehensive graph represents the entire company's product data, subgraphs might represent specific domains, such as R&D, Production, Aftermarket, Procurement, and further customizable domains as subgraphs.

The supergraph is the culmination of our efforts, representing the entire product ecosystem:

  • Unified view: These subgraphs are integrated into a supergraph, providing a unified view of the entire system.
  • Cross-domain insights: By integrating data from various subgraphs, the supergraph enables insights that span multiple domains.
  • Independent management: Subgraphs can be managed and updated independently, allowing for focused and efficient data handling.
  • Enhanced decision-making: This comprehensive view is crucial for informed decision-making, allowing engineers to see the impact of changes across the entire system.

It serves as a single source of truth, showing in an adaptable manner how the system works. This enables efficient queries, e.g. for error isolation and dependency tracing – providing significantly enhanced querying capabilities compared to traditional relational databases.

For instance, assuming a type in the schema dedicated to engine specification exists in the subgraph governed by the R&D department, then addition of fields related to estimated power output could immediately be consumed in context of an overall vehicle performance analysis, thanks to the supergraph.

2.7 GraphQL

GraphQL is the query language used for interacting with the Engineering Intelligence Graph. It provides a flexible and efficient way to request data:

  • Selective data retrieval: Users can specify exactly what data they need, reducing over- and under-fetching. For instance, a user can query for specific attributes like engine temperature and software version without retrieving unnecessary information.
  • Single endpoint access: All queries are sent to a single GraphQL endpoint, simplifying the interaction process. If a query requests fields hosted on different subgraphs, federation takes care of distributing requests under the hood.
  • Nested queries: GraphQL allows querying related data in a single request. For example, you can fetch a car’s engine details along with its maintenance history in one go.

This precise and efficient data retrieval mechanism is crucial for engineering teams who need quick access to specific data sets. Or differently put: the Engineering Intelligence Graph is not just a cross-domain schematized database, but unified access over federated infrastructure of subgraphs enabling and leveraging advanced analytics and the knowledge base for LLMs as further capabilities.

 2.8 Flexible platform access and usage

As our system’s architecture is highly modular and all interactions pass through the federated graph layer, our client’s cases can be solved in diverse scenarios:

  • They can use our API as a product, building their own applications on top (in our Action Cloud layer or with any other framework that provides a GraphQL client).
  • They can contribute to a common modelling initiative aiming for standardization.
  • In the future, they can provide their own subgraphs to be federated with our pre-built domains, where such subgraphs can be proxies to already existing REST APIs or databases. Further, they can use our schema-editing and code generation tools to build their own subgraphs for the supergraph.

To give complete interaction capabilities with any number of external systems, our graph layer can be configured to process external events or calls, as well as emit events to external systems, and be connected with other graphs.

3 Action Cloud with Agentic Engineering Intelligence

Third step: The Action Cloud is the representation and interaction layer, where the structured and contextualized data in the Product Twin is leveraged to enable access, analysis and authoring of product data. This enables the usage of pre-configured Engineering Intelligence Solutions, as well as the low-code building of customized applications in the Studio. The Action Cloud is further enhanced by Engineering Intelligence Agents that operate to streamline workflows and automate engineering tasks.

3.1 Engineering Intelligence Solutions & Studio Customizations

The Action Cloud provides users with multiple pre-configured Engineering Intelligence Solutions, while also enabling the users to easily build custom applications in a low-code environment within the SPREAD Studio. The solutions and applications enable users to visualize and interact with their product data but also analyze and author the data within the Engineering Intelligence Graph. Furthermore, users can easily share the applications and visualization with selected external partners, while ensuring compliance with regulatory standards.

3.2 Engineering Intelligence Solutions

The Engineering Intelligence Solutions offer user-friendly and specialized applications in which engineers can easily interact with their data across the complete product lifecycle, from R&D and Production to Aftersales. These out-of-the-box solutions are designed to support engineers at every phase of the product lifecycle, improving collaboration and enabling faster, data-driven decisions.

SPREAD currently offers the following out-of-the-box solutions, which are based on our experience with our clients in the past 5 years:

  • Product Explorer: Explore the product architecture by navigating requirements, configurations, and dependencies, as well as assembly and repair sequences across variants (e.g. Feature Dashboard).
  • Product Architect: Define and refine requirements and link functions and design components to align R&D with Production, and generate repair sequences and Aftermarket workflows (e.g. Planning Assist).
  • E/E Inspector: Identify and resolve Electric/Electronic (EE) issues early by linking errors to system dependencies and uncovering recurring patterns (e.g. Issue Ticket Analyzer).
  • Action Tower: Sync R&D, Production, and field data to gain control over function maturity, change impact, releases, as well as error management, product performance, and diagnostics (e.g. Feature Maturity Dashboard).
  • Upskilling Coach: Bridge knowledge and product data gaps for Production and Aftermarket success by providing access to variant deltas, learning paths, and guidelines.

Blog_1920_4

3.3 SPREAD Studio Customizations

The SPREAD Studio provides engineers with a low-code environment where they can intuitively build custom applications and dashboards, automate complex tasks and retrieve data. The user-friendly drag-and-drop interface and low-code environment empowers engineers and users with minimal or no programming knowledge to build and deploy applications. This enables a broad set of users to generate value in a short amount of time. Here are some examples of use cases:

  • Business process automation: Non-technical staff can automate workflows, improving efficiency and productivity.
  • Data analysis and visualization: Users can generate reports and dashboards by simply describing their data and desired insights.
  • Prototype development: Rapidly create and test new ideas without the need for extensive coding resources.

Blog_1920_5

How does it work in practice: The users can intuitively build the application within a simple visual interface. Within the interface they can easily drag-and-drop pre-built widgets (e.g. 2D/3D visualizations, graphs, tables) to build their application or dashboard. The function, reference or logic of these widgets can then easily be customized and specified through low-code adjustments within the same interface. All of this is further supported by real-time visual feedback, enabling the user to directly see the result of their changes.

Additionally, users can build Flows within the visual drag-and-drop and low-code environment of the SPREAD Studio. Flows empower users to process data, execute data tasks and define data rules within the SPREAD ecosystem. The Flows empower users to fetch data from external sources, transform data from the platform to an external application or improve data handling within applications and solutions. The flows themselves can be triggered by an API, time or other initiators.

Blog_1920_6

3.4 Agentic Engineering Intelligence

Everything SPREAD does and sees is defined as data in our Engineering Intelligence Graph. This data is described and understood by both humans and machines. The graph provides secure access to all your data incorporated into our platform capabilities. Our EI agents are routines that take an input and provide an output based on instructions, tools and data they have access to. This is what sets SPREAD’s EI agents apart: providing the agents with our platform capabilities and data as the toolbox they can operate on, within the restrictions you set. The EI agents work based on all the structured and contextualized knowledge within the Engineering Intelligence Graph, enabling expert and highly specific support of the user. The agent’s knowledge can be further enhanced by an expert user providing additional context and data (e.g., requirements) to train the agent with additional details.

The EI Agents can streamline and automate a broad set of tasks. This includes tasks like data authoring, analysis and mapping, but also high-value tasks, like requirements analysis, error pattern analysis and concept building. The users can specify and define the agent’s capabilities themselves to concretely address the engineer’s needs and resolve the specific problem at hand. Some of these high-value engineering tasks include:

  • Requirements analysis: By considering technical constraints and relevant regulations, EI agents help to identify dependencies and derive technical specification (e.g. what value is set for a signal according to a requirement).
  • Specification creation: EI Agents can help understand, translate, and generate requirements and specification documents based on historical data.
  • Data mapping: EI Agents can help to connect and map new data to existing data and relationship to enhance the Product Twin.

The interaction with the EI Agents works using conversational natural language prompting. But as they are seen as data as well, they can be used throughout all layers by using our unified API. Users from all domains can ask the agents to perform tasks or answer certain questions within a simple and intuitive interface. The agents then interpret the instructions to generate the corresponding workflows, conduct analysis and provide solutions. This intuitive way of interacting with the agentic AI makes it accessible and easy for engineers to utilize the power of the agents. Further, agents can interact with each other and use their specific knowledge in order to complete a given task.

Ultimately, the EI Agents free up the engineers and enable them to focus on high-value engineering tasks.

4 Foundations of our platform

Our platform foundations support secure data hosting, sharing and multi-tenant management. These layers ensure user authentication, data integrity, and compliance across global teams and partners, allowing SPREAD’s solutions to be securely shared within organizations and with external stakeholders.

4.1 Hosting


Supporting SPREAD’s core layers is the Hosting layer, which provides scalable, secure deployment options, including customer private cloud, on-premises, and SPREAD’s multi-tenant cloud.

Key features include:

  • Data isolation and security: Each client’s data is securely isolated with strict access controls.
  • Scalability: Resources are dynamically allocated, adapting to changing demand.
  • Flexible deployment: Options for private cloud, on-premises, or multi-tenant cloud, ensuring each client’s security and infrastructure needs are met.

4.2 User Management


Our User Management application enables the seamless management of user authentication, authorization, and access control within the platform. This is essential in maintaining a secure and efficient environment. Administrators can easily define user roles, assign permissions, and ensure that individuals have appropriate access to data and tools based on their responsibilities.

4.3 Data Management

The Data Management application in SPREAD’s ecosystem oversees the governance, storage, and retrieval of product data. It provides accessible tools for organizing, querying, and managing the lifecycle of engineering and product-related information. This ensures data integrity and compliance with both internal and external requirements.

4.4 Tenant Management

The layer enables the management of tenants on a multi-tenant SPREAD deployment, maintaining isolation and flexibility. It allows administrators to easily segregate data, configurations, and user environments for different clients or teams. This ensures secure access and tailored functionality for each tenant.

5 Get to see it for yourself

It's one thing to read about it, it's a completely different thing to see it in action. If you'd like to know more about our solution and how it works. If you have any further questions, please don't hesitate to contact one of our experts. Just book an individual session - with no strings attached.