Introduction

AM builds artifacts by large numbers of processing steps from small- to high-length scale, and the properties of the products may be sensitive to the design and variability of the manufacturing processes. A low technology readiness level (TRL) AM project may introduce off-nominal processes to explore the design space throughout the material life cycle. In such an R&D project, a general material life cycle starts from feedstock to processes and ends at measurements to acquire data for the optimization of the design parameters. This life cycle is only a portion of other perspectives for sustainable materials managements or a mass production business. In a production procedure with higher TRL, to control the process variations, such as laser scanning path, acquires a large set of information for the root-cause analyses. Effectively managing and learning from complex datasets can efficiently improve the TRL of the AM technology.

Focusing on different perspectives for R&D projects, the design of the database architecture has unique features depending on the data flow and project objectives. Data architecture refers to a structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets and data management resources.1 Some architectures, like basic formal ontology (BFO)2 and industrial ontologies foundry (IOF),3 are proposed to construct the domain independent ontology for building up domain-specific ones. Different types, classes, nodes and relationships are proposed to construct objective-oriented ontologies targeting materials chemistry, manufacturing steps, product properties or other engineering approaches.4,5,6,7,8,9 Efforts are also made to resolve broader issues on the system engineering level for different objectives and different users.10,11 These efforts may not be proposed to address the AM issues, but the metadata and the data models can be reused for other data model developments.

The data generated from R&D projects can be complex for the project managements of the material life cycle through different processing history. The reuse of the existing data models needs an eco-system in a generic data architecture to cost-effectively build up a database. To mitigate some of these gaps for general manufacturing processes, several efforts, such as the Quality Information Framework12,13 and MTConnect,14 are proposed by engineering communities. The ASTM F42.08 working group proposes the Common Data Dictionary, Common Data Model and Common Data Exchange Formats to accelerate the development of the data architecture across alliances.15 HyperThought,16 AMMD17 and AM Bench are the informatic systems containing different data architectures for AM projects. Learning from these, even the metrics to evaluate AM processes are still not clear, and there is high similarity of the data flows compared to the conventional manufacturing technologies. It is valuable to develop a data warehouse that leverages the existing efforts to address the materials life cycle for R&D AM projects.

The design of AM operation conditions may introduce different feedstock materials and tailor processing steps accordingly to satisfy the project objectives. The feedstock materials may be prepared in different batches by different manufacturers for the optimization of the processing steps. These sequential processes include thermal and/or thermomechanical treatments applied under different rates for certain durations. Of course, AM is one of them. To evaluate the combination of the material and processing history, measurements may interrupt the manufacturing schedule and represent the end of a material life cycle in an R&D project. These AM-related activities are designed to develop the knowledge base for optimizing the processing conditions for a targeted material.

To cost-effectively assist the exploration of a complex knowledge space, a design of data pedigree for AM to handle the information can be challenging. Fortunately, many standards have yielded results for the terminologies and registrations of data. For example, ISO 8000 is a well-adopted standard for data managements and data quality assessments.18 For additive manufacturing, ASTM F2792 provides and defines the terminologies on AM technology and powder materials for metal parts.19 This standard has been further developed into data models and ontologies for managing and exchanging both technical and non-technical data from AM projects.15 Similar work can be found from project AM Bench 2018 that contains models to save metadata of several types of measurements.20 On top of these efforts, plans for data registration are needed, and ISO DIS 52953 guides data registration procedures and methods to align in situ and ex situ data for metal additive manufacturing.21 These efforts resolve some of the challenges while building a database; however, the top-level metadata of project background and the integration of the sub-models are still needed. This work proposes a scalable data structure to integrate and bridge the gaps among the domain-specific models for AM projects.

Data Model Pedigree

The development of the AM technology may often evaluate a combination of different building strategies and material processes. Different from mass production workflows, the database architecture for AM R&D projects needs to be scalable to accommodate new types of information without changing the major database architecture. Fortunately, the schedule pipeline of an AM process is similar to other manufacturing technologies, and we can leverage the published works for the development of the data architecture. This work proposes five data models to create a hierarchy, covering project management, feedstock material, processing steps, measurement and numerical simulation. These models are connected by identifiers to enable the traceability along the material history and support the extensibility of the data structure. Each data model contains multiple data classes that are built-up by fundamental data types to organize the information in different categories.

The proposed architecture is presented in Fig. 1. The top layer is a Project model that contains a unique ProjectID to label the following data hierarchy. The second layer of the architecture is a Material model. Since a project may evaluate different materials from different batches or manufactures, each material record not only inherits the projectID, but also holds a sequential, integer ID to initiate branches of the processing history. Different from the independent material information, a manufacturing history is a time series of processes. For example, a simple AM experiment may include four processing steps: powder blending, AM building, stress relief and machining. Each is assigned a sequential identifier to arrange the steps. When considering the applications of process optimization, this ProcessID is a high-dimensional array to distinguish the branches of the processes. In this proposed architecture, ProjectID needs to be unique in a data system, but MaterialID and processID can be sequential in a project dataset.

Fig. 1
figure 1

A schematic data pedigree is designed to save additive manufacturing related data.

Full size image

After manufacturing, measurements may be scheduled in parallel to evaluate AM products that generally include the structure characterizations and property tests. The data hierarchy in Fig. 1 is designed to save these two classes of measurements separately. The overlapping information between these classes are ProjectID, MaterialID and ProcessID to create critical linkages among structure and properties.

Different from measurements, the scopes of the computer simulations can be diverse to approach different relationships of experimental results. A data model for simulations needs to be flexible to link the inputs and outputs from the measurement records. The proposed data structure uses identifiers pointing to the targeted physical quantities of specific experimental records.

To demonstrate the architecture of the data pedigree, Fig. 2 uses a project from America Makes.22 The material record contains projectID (4009), which links the project background information. Two building tasks are accomplished using the same material and two types of AM technologies. The details of each process are saved in one record that includes the projectID and materialID. The results from microstructure characterization and property tests are saved separately but may inherit the same identifiers of Project, Material and Process according to the material history.

Fig. 2
figure 2

The workflow of project 4009 from America Makes demonstrates the data pedigree.

Full size image

Domain-Specific Models

The proposed data architecture contains 729 types and 55 classes for 5 data models to save the details of an AM project. Due to the complexity of the model details, this work only highlights the connections of the data architecture. However, the definitions of the fundamental types are implemented using XML that can be found from the attachments.

Project Model

The top level of the project model is constructed using the seven elements listed in Table I. Except the ProjectTitle and ProjectID, the classification level of the data security is the most important one among all the information, and the ITARClassification is an element to claim if the project deliverables are controlled. Description is the abstract of the project. ProjectSummary targets business focuses, and this work follows the requirements from America Makes to save performance organization and principal investigator, etc. It also requires the ownership of the background intellectual properties. Keywords keep additional information for enhancing the findability of the project records, and attachments provide the in-depth information for future applications.

Table I The top-level elements are defined in the project model
Full size table

It should be highlighted that the Attachment Type is repeatedly reused in different models connecting metadata to raw or large tabular data. This type requests an ID to count the number of attachments, a string to describe the file and the location of the file.

Feedstock Material

The metadata for feedstock material are similar to those for other manufacturing technologies, including the vendor information, composition and certification. To summarize these metadata, a Chemistry class is defined to accommodate the material grade, composition and properties. The Grade element enumerates strings of common material names, such as IN718 and 17-4PH. Composition is a class to save chemical composition, and the Property element is reserved to save the properties, like the physical and chemical properties, of the feedstock material. Certificate is a space to keep the certification of the material. A list of top-level classes can be found in Table II.

Table II The elements are defined in the material model
Full size table

The most unique feature of the feedstocks for AM is that the material can be prepared for different shapes, such as wire, powder and sheet, etc., for different AM processes. This feature leads to the development of the MaterialForm class, shown in Table III. MaterialForm consists of Form, Status and Dimension; it is designed to describe the feedstock material. Form is a type of string enumerating a list of descriptions for user selection. Status is recorded if the material is recycled from previous processes. The Dimension class is proposed to save the geometry of the feedstock. The direction is a string type that can be X Y or Z for defining a Cartesian coordinate system or size distribution for powder depending on the applications. With the value and unit, the Dimension type covers simple shapes of feedstock.

Table III The description of the MaterialFrom class
Full size table

Processing

Process model sits on the third level of the pedigree, which inherits ProjectID and MaterialID to identify the relationships of the records. MachineSetup is a preliminary data class requiring high-level information about the service provider, type of AM technology, machine information, operation software, laser system, recoater, in situ monitoring system and attachment. The type of AM technology is an enumeration of process category that is defined by ASTM, including Binder Jetting, Directed Energy Deposition, Powder Bed Fusion, Sheet Lamination, Material Extrusion, Material Jetting and Vat Photo Polymerization.23 Following machine setup is the AM building that includes the design of part, scanning strategy and in situ monitoring signals. The machine and building classes are intentionally designed to accommodate different types of AM technology.

After AM building, PostBuildingProcess is a class designed to save the processing history. Because the thermal and thermomechanical treatments are commonly aligned after AM building, PostBuildingProcess provides an example to handle different designs of the treatments at different temperature, time, applied forces and their rates. Each processing step is labeled by a sequential ID. As shown in Fig. 1, the processing history contains a two-dimensional array to label the sequence of the treatments. Other types of processes such as machining and surface treatment can be recorded using this model as well (Tables IV and V).

Table IV The top-level elements are defined in the processing model
Full size table
Table V The elements are defined in the data model for measurement
Full size table

Measurement

Containing the IDs of project, material and process, Measurement is a record in the end of the data pedigree saving the raw data from microstructure characterizations or properties tests. The location on build and size of specimen are the generic information for different types of measurements, and Specimen is a class describing this background information. Because many types of measurements are destructive, the microstructure features from characterization may not be representative of but highly correlated to the specimens for properties tests. Direct comparison among a measurement of microstructure character and tested property may be misleading. An example is often seen where a witness coupon and a tensile coupon are built in the same process. The former is built for microstructure characterization and the latter is for tensile properties. The process variability at different locations on a build plate can increase the uncertainty when identifying the relationships between these measurements. To avoid the confusion for future analyses, each measurement record only saves a set of either microstructure or property data.

The location-specific properties are of interest to many AM projects, and a definition of a measurement “sample” needs both a location on the plate and a location of the part along with the preparation history. In this work, a part is defined as an AM-fabricated object and a specimen is extracted from a part for specific measurements. For example, a specimen is cut from an interested location of a part before polishing and etching for microstructure characterization. The locations, preparation history and operation parameters are important metadata for measurements. This work adopts the definitions and data models from AM Bench 2018 and AMMD.17,20 More details can be found from attachments.

Simulations

The Simulations model is constructed by 12 elements that are listed in Table VI. ProjectID is a unique identifier connecting this simulation record with the data pedigree. Background is a class of elements containing CodeTitle, Objective, Version and ProgrammingLanguage to save the information of a simulation code. The Developer element holds a space to save the organization, name, and email of the code developer. TrainingTime and TrainingData save the model training history if there is any. SourceCode is an element designed for open-source software that the schema users can keep and share the code as attachments. ModelInputs and ModelOutputs are the I/O to the simulation that need the information about the name, value, unit and uncertainty of each I/O variable as the ModelIOType defined in Table VII. Additional file or note can be kept with this record using the Attachment and Note elements.

Table VI The elements are defined in the data model for simulation
Full size table
Table VII The definition of the ModelIOType
Full size table

Use Case

To demonstrate the complex connections of this data architecture, a set of project deliverables from America Makes is presented using XML. This selected project builds coupons using IN625, IN718 and IN718plus for the measurements of melt pool geometry and tensile properties at various temperatures. The thermal properties, such as heat capacity, thermal conductivity and solidus temperature, etc., are assessed using differential scanning calorimetry. The experimental data are the inputs to the models for simulating the distortion of the as-built parts, which is validated with the experimental results. This use case addresses the key connections for building up a data architecture.

Inheriting the project ID, three records, with sequential material IDs in Fig. 3, are created for the materials data. These records contain material grade, alloy composition and material formats, etc., that lead the preparation of the processing records. Figure 4 presents a comparison among building plans, which are designed for the AM machines. After AM building, the same procedures are applied to all the coupons from different builds, and the experimental data are used to validate the simulations. A sample data file for simulations is presented in Fig. 5. This use case demonstrates the traceability and scalability of a data warehouse that enables strict data acquisitions for such an early R&D project. More importantly, this data architecture can accommodate the additional data models for future developments.

Fig. 3
figure 3

Portion of three material records demonstrates the different tasks of a project from America Makes.

Full size image
Fig. 4
figure 4

Process records save the information of the machines and scan strategies of three tasks.

Full size image
Fig. 5
figure 5

The records save the software packages used in project ID 4026.

Full size image

Conclusion

This work proposes a data architecture focusing on the metadata for the AM practitioners from materials engineering. It leverages the domain-specific data models from public databases to record the material life cycle from project planning and processing to measurements that are generic to AM technologies. The future development will include community efforts, such as ASTM AM-CDD and AM-CDM, to standardize the data architecture for the management of AM data.