Machine Automation Technology 2021
Veli Viisanen
DATA MODELING
– Development of data models for the results of
mechanical testing of metals
2021 | 38 pages, 7 pages in appendices
Veli Viisanen
DATA MODELING
-Development of data models for the results of mechanical testing of metals
This Bachelor’s thesis presents the process of data model development for the results of mechanical testing of metals. The thesis was carried out during the early stages of the commissioning party Electro Optical Systems Finland Oy’s ongoing digitalization initiative where the goal is to harmonize the company’s internal data processes and storage systems. The thesis aimed to generate harmonized data models for a narrow selection of mechanical test types and produce training material about database systems and data modeling process for a modern document-based non-relational database management system.
In the theoretical framework information about different database management systems collected from related literature is presented to form an overall view of the most common database system solutions and the process of data modeling is introduced. Also, in order to clarify the context and origin of the data of interest, literature and test standards were studied, and colleagues were interviewed to gather general information about mechanical testing of metals and additive manufacturing.
The implementation chapter of the thesis describes the process of data model development for the results of the most common types of mechanical testing. As a result, six different physical data models were developed. One of the developed data models was implemented in a prototype testing environment and the test case is briefly presented in conjunction with preliminary plans for the next steps to be taken with the collected data. The thesis concludes with an observation that the data modeling process is a very usable technique in database development especially in an environment where other stakeholders involved are not familiar with software and database development.
KEYWORDS:
data model, database, SQL, NoSQL, additive manufacturing, mechanical testing
2021 | 38 sivua, 7 liitesivua
Veli Viisanen
TIETOMALLINNUS
-Tietomallien kehittäminen metallien mekaanisen aineenkoetuksen tuloksia varten
Opinnäytetyö esittelee tietomallien kehitysprosessin metallien mekaanisen aineenkoetuksen tuloksia varten. Työ toteutettiin osana toimeksiantajana toimineen Electro Optical Systems Finland Oy:n käynnissä olevaa digitalisaatiohanketta, jonka tavoitteena on yhdenmukaistaa yrityksen sisäisiä tiedonkäsittely- ja tallennusjärjestelmiä. Opinnäytetyössä luodaan yhdenmukaiset tietomallit pienelle valikoimalle mekaanisia aineenkoetustapoja ja tuotetaan koulutusmateriaalia yleisimmistä tietokantajärjestelmistä sekä tietomallinnusprosessista modernille dokumenttipohjaiselle tietokantajärjestelmälle.
Teoriaosuudessa esitellään yleiskatsaus yleisimmistä tietokantajärjestelmätyypeistä sekä tietomallintamistekniikoista. Datan alkuperän ja asiayhteyksien selventämiseksi työssä käsitellään katsauksen omaisesti myös ainetta lisäävää valmistusta sekä metallien mekaanisen aineenkoetuksen yleisimpiä metodeja perustuen kirjallisuudesta, standardeista ja kollegoilta kerättyyn tietoon.
Toteutusosuudessa kuvaillaan tietomallintamisen prosessi läpi vaiheittain, sekä esitellään työn tuloksena syntyneet kuusi tietomallia. Yhden tietomallin kehitysympäristössä tapahtunutta käyttöönottoa ja testausta sivutaan lyhyesti, ja lisäksi työssä pohjustetaan myös alustavia tulevaisuudensuunnitelmia jo kerätyn datan yhdenmukaistamiseksi. Työn johtopäätöksenä todetaan tietomallinnusprosessin hyödyllisyys osana tietokantajärjestelmien suunnittelu- ja dokumentointiprosessia etenkin, jos prosessissa on mukana henkilöitä, joiden käsitys ohjelmisto- ja tietokantakehitystyöstä on rajallinen.
ASIASANAT:
tietomalli, tietokanta, SQL, NoSQL, ainetta lisäävä valmistus, mekaaninen aineenkoetus
1 INTRODUCTION 6
2 DATABASE SYSTEMS 7
2.1 Components of the database system 7
2.1.1 Users 8
2.1.2 Database applications 8
2.1.3 Database management systems 8
2.1.4 Databases 9
2.2 Main database system types 9
2.2.1 Relational databases & SQL 9
2.2.2 Non-relational databases & NoSQL 11
3 DATA MODELING 14
3.1 Types of data models 14
3.2 Entity-relationship model 15
3.2.1 Crow’s Foot notation 16
3.3 Levels of modeling 17
4 ADDITIVE MANUFACTURING & DMLS 19
5 MECHANICAL TESTING OF METALS 21
5.1 Tensile strength 21
5.2 Hardness 23
5.3 Impact toughness 24
5.4 Creep & Stress rupture 25
5.5 Fatigue 26
6 IMPLEMENTATION 27
6.1 Modeling process 28
6.1.1 Conceptual modeling 28
6.1.2 Logical modeling 29
6.1.3 Physical modeling 29
6.2 Implemented physical data models 30
6.2.1 Common data model 30
6.2.2 Test specific models 31
7.1 Tensile strength test case 34
7.2 Plans for legacy data 36
7.2.1 Automatic conversion 36
7.2.2 Manual conversion 37
8 CONCLUSION 38
REFERENCES 39
APPENDICES
Appendix 1. JSON data types Appendix 2. Common data model Appendix 3. Tensile strength data model Appendix 4. Hardness data model
Appendix 5. Impact toughness data model Appendix 6. Creep & Stress rupture data model Appendix 7. Fatigue data model
FIGURES
Figure 1. Force-elongation and stress-strain curve (ASM International 2004, 4). 22 Figure 2. Tensile strength, yield strength, young’s modulus (Rösler etc. 2007, 70). 23 Figure 3. Absorbed energy-temperature curve (ISO 148-1 2006, 19). 24 Figure 4. Strain accumulation during standard creep test (Penny & Marriot 1995, 2). 25
Figure 5. S-N curve (ISO 1099 2017, 15). 26
PICTURES
Picture 1. Hierarchical data storage example (Beaulieu 2020, 3). 7 Picture 2. Relational data storage example (Beaulieu 2020, 5). 10
Picture 3. JSON-formatted document example. 12
Picture 4. Example of an entity and two entity instances. 15 Picture 5. Example of two entities associated in a relationship. 15
Picture 6. Crow's Foot notation cardinality symbols. 16
Picture 7. Crow's Foot notation example. 17
Picture 8. Examples of conceptual, logical, and physical data models. 17
Picture 12. Tensile strength results in Excel spreadsheet 34 Picture 13. Tensile strength result as a JSON-object. 35
AM Additive Manufacturing (Brandt 2017, 1).
ANSI American National Standards Institute
DBMS Database Management System, a computer program used to create, process, and administer the database (Kroenke &
Auer 2013, 13).
DMLS Direct Metal Laser Sintering, a type of metal additive manufacturing (Bian etc. 2018, 201).
ISO International Organization for Standardization
JSON JavaScript Object Notation, a lightweight, text-based, language-independent, and human-readable syntax for defining data interchange formats (ECMA 2017, 1).
SQL Structured Query Language, a data sublanguage for
relational database defining and processing (Kroenke & Auer 2013, 109).
1 INTRODUCTION
The subject of this thesis is the development of harmonized data models for the results of mechanical testing of metallic test specimens manufactured with additive manufacturing methods. The aim is to create data models that represents how the data is stored in a database for a narrow selection of mechanical test types and simultaneously explore the subject of data modeling and generate internal training material about most common database systems and data modeling for modern document-based non-relational database management system.
In addition to data modeling, also subjects like database systems, relational and non- relational databases, mechanical testing of metals and additive manufacturing will be briefly touched to clarify the context and origin of the acquired data. Thesis will be implemented as a part of Electro Optical Systems Finland Oy’s digitalization initiative where the goal is to harmonize internal data processes and storage systems. Eventually the acquired test data is to be utilized for analytical and commercial purposes.
Electro Optical Systems Finland Oy is a subsidiary of the German company EOS GmbH.
As a pioneer of additive manufacturing and so-called Direct Metal Laser Sintering technology, EOS GmbH is the leading technology provider worldwide for industrial 3D printing of metals and plastics. Globally, EOS GmbH employs more than 1300 personnel, of which EOS Finland employs about 60. EOS Finland’s main task is to develop and supply materials and process methods that are sold to EOS GmbH's customers. EOS Finland specializes in the development of metal powders and laser processes used in additive manufacturing. Today, AM metal components are used in many high-standard and demanding applications such as medical devices and aerospace components.
2 DATABASE SYSTEMS
Every day the understanding of database technologies increases in importance.
Databases are everywhere and they are the fundamental components in enterprise operational and decision-making applications. (Kroenke & Auer 2013, 3.) Much like a telephone book, a database is a set of related information. Eventually the cumbersome nature of manual data storage systems such as telephone books and filing cabinets resulted in the development of electronic data storage and so-called database management systems (DBMS). Computerized data storage and retrieval systems were some of the first computer applications developed and because the data in databases is stored electronically rather than on a physical media, access and the possibility to update data is faster and far more flexible. First generations of computerized database systems were so called non-relational databases where data could be stored for example in a tree-like hierarchy as seen in picture 1. (Beaulieu 2020, 1–3.)
Picture 1. Hierarchical data storage example (Beaulieu 2020, 3).
2.1 Components of the database system
In general, database systems have four main components: users, database applications, the database management system, and the database. The database is a collection of related tables and structures. The database management system is a computer program, that receives requests encoded in system specific language and translates those requests into database actions. The database application is an intermediary program, frequently in-house developed, between the user and the database that sends requests
to the database management system based on the user actions. The final component, users, are the ones who employ database applications to read, query and enter data.
(Kroenke & Auer 2013, 13.)
2.1.1 Users
The users of the database systems are the people who require access to the data stored in a database. Typically, in enterprise operations users can be broadly categorized in four categories based on their roles; application users, sophisticated users, application programmers, database administrators. Application users utilize some database application to perform their daily tasks which involve for example querying and updating data and generating reports. Sophisticated users have some other self-defined method to access the data, possibly their own application or by directly using query languages.
Application programmers design, develop and implement database applications based on requirements defined by other stakeholders. Database administrators are the persons responsible of the whole database management system. (Watt & Eng 2014, 91–92.)
2.1.2 Database applications
Usually, database application refers to a specific database and the associated software that implement the database queries. As an example, a database application used for tracking bank customers account balances would have features that correspond to the customers deposits and withdrawals. The database application could be considered as a user interface for the database with features dictated by the application specific requirements. Traditionally, the design and implementation of database applications leans more towards software development than database design. (Elmasri & Navathe 2007, 57.) Nowadays the majority of web services could be considered as database applications, and especially the rise of cloud-based technologies has blurred the distinction between database and desktop applications.
2.1.3 Database management systems
Database management systems are large, complex software products designed to administer, create, and process databases. A database management system maintains
database supporting structures like indexes, it processes request to read and modify data and it enforces rules about data values. Finally, database management system has multiple functions regarding database administration: the control of concurrency so that one user’s work does not interfere with another user’s work, management of security and ensuring that only authorized users perform authorized actions and providing facilities for backing up and recovering the data. (Kroenke & Auer 2013, 15.)
2.1.4 Databases
“A database is an organized collection of structured information, or data, typically stored electronically in a computer system. A database is usually controlled by a database management system (DBMS). Together, the data and the DBMS, along with the applications that are associated with them, are referred to as a database system, often shortened to just database.” (Oracle 2020)
Databases have gone through quite a profound evolution since their first steps in the 1960s. Navigational databases, such as the hierarchical and the network model, were the original database systems used to store and manipulate data. While simple, these models were not very flexible. Relational databases became popular in the 1980s and have triumphed ever since. The massive growth of the internet and the need for faster processing of unstructured data has accelerated the demand for so called NoSQL databases. (Oracle 2020)
2.2 Main database system types
Database systems can broadly be classified in two main categories. Relational database systems have been the industry standard since their inception during the 1970s while the rise of internet related technologies in the early 2000s have incited the development of so called non-relational database systems.
2.2.1 Relational databases & SQL
A relational database model originates from the 1970s when IBM’s Dr. E. F. Codd released a paper called “A Relational Model of Data for Large Shared Data Banks”
proposing that data should be represented as a set of tables (Picture 2) linked together using redundant data (Beaulieu 2020, 5). Each relation, or table, is designed to store
data about a single theme and after individual tables have been designed, a redundant column is added to each table to show the relationship from a tuple, or row, in one relation to a row in another relation (Kroenke & Auer 2013, 51).
Picture 2. Relational data storage example (Beaulieu 2020, 5).
Alongside the development of a relational database model, a data sublanguage called Structured Query Language (SQL) was developed by IBM Corporation specifically for relational database defining and processing. Successive versions of SQL language have been endorsed as a standard by both American National Standards Institute (ANSI) and International Organization for Standardization (ISO). (Kroenke & Auer 2013, 109.) In enterprise applications, relational databases and SQL have been the default choice for serious data storage for decades. They have become an embedded part of computing culture for multiple benefits they provide, most obvious one being the ability to store large amounts of persistent data that can be organized in all sorts of ways. Enterprise applications tend to have multiple users working with same body of data at the same time and coordinating these concurrent interactions is both vital and extremely difficult.
Relational databases handle this by controlling all data-access through SQL transactions that play a key part in error handling; transactions enable you to roll back if an error occurs during the processing of the change you made. Although there are differences between database vendors, the basic relational model and core mechanisms remain the
same with only minor differences in SQL dialects. Because of these benefits, relational databases have succeeded and have become a standard solution for many projects.
(Sadalage & Fowler 2013, 1–5.)
The implementation of a relational database model always includes the design of a database schema. Schema is an abstract design representing the structure of the stored data and the relations between tables inside the database. A database schema could be considered as the blueprint of the database system, defining how the data will look.
(Educative 2020)
2.2.2 Non-relational databases & NoSQL
The need for next generation databases was fueled by the massive growth of different web services, social media and the sheer volume of unstructured data collected in the 2000s. The exponential growth led to the development of non-relational data storage solutions that unlike traditional relational databases could be easily scaled and split across multiple servers. (Zhu etc. 2014, 78–79.) The term “NoSQL” is an umbrella term for a multitude of technologies focusing on data storage methods alternative to traditional relational model. The term, which got widespread recognition after a software developer meetup in 2009, is not really a generally accepted definition, but more of an indication of common characteristics the database management system has: not using the relational model, running on clusters, open source, built for 21st century web services, schemaless.
(Sadalage & Fowler 2013, 9–12.)
NoSQL-databases can be broadly categorized into four different groups: key-value stores, document databases, columnar databases, graph databases. Key-value store is a global collection of key-value pairs, where the values can contain any arbitrary data type that the application used can interpret. Document databases contain documents or records that both describe the data and contain the actual data itself. These documents can contain complex nested structures to provide subcategories or additional information about the stored objects. Columnar databases were designed to read and write data effectively from hard disk storages. They store data in columns instead of rows which especially improves both performance and storage requirements and provides self- indexing. Graph databases, unlike other database types, are designed to work as fast as possible with high volumes of high complexity data found especially on social networks and recommendation engines. In graph databases the data is also the
structure: set of objects connected by a set of relations with a set of descriptive properties. (Zhu etc. 2014, 80–82.)
I.e., MongoDB is a popular non-relational database management system launched in 2009. In MongoDB the basis of storage are collections of human-readable JSON- formatted documents (Picture 3) with keys and values instead of traditional relational database management systems tables with columns and rows. This enables the direct as-is storage of programmatic objects representing information that needs to be stored.
(Bierer 2020, 10–11.)
Picture 3. JSON-formatted document example.
From development perspective, the biggest source of frustration with relational model since its early stages has been the so-called impedance mismatch; the difference between the relational model and the in-memory object structure. While the tables and rows, or relations and tuples, structure of relational model provides certain elegance and simplicity, it comes with severe limitations too. For example, the value in relational tuples needs to be simple; they cannot contain data structures like nested records or lists.
Working with rich in-memory data structures means that the structure must be translated to a relational model for storage resulting in two different representations that require translation. (Sadalage & Fowler 2013, 5.)
As object-oriented programming languages have become more and more popular, transforming the data of interest from object-oriented format as seen in picture 3 to tabular format like in picture 2 for storage has become a pointless and time-consuming, and thus an expensive, process. All modern object-oriented programming languages (C#, Java, JavaScript, Python, Ruby just to name some) provide extensive support for producing and reading JSON-formatted data or utilize JSON-compatible built-in data
structures directly so the impedance mismatch can be largely avoided for example by utilizing document-based databases and JSON-formatted documents.
3 DATA MODELING
“Data modeling is not optional; no database was ever built without at least an implicit model, just as no house was ever built without a plan.” (Simsion & Witt 2005, preface)
Data modeling is essentially a type of documentation process, where the goal is to illustrate the data types and relations used within the database system and to create a living visual representation that evolves with business needs. The modeling can take place on multiple levels of abstraction and usually the process begins with collection of information and requirements from stakeholders and users to form a conceptual model.
Collected rules and requirements are then refined into a database design and data structures. Data modeling should be an iterative process that assists developers and other stakeholders to understand and refine the relations among the data as needs and requirements change. (IBM 2020)
3.1 Types of data models
Most common data model types in database modeling are hierarchical model, relational model, network model, object-oriented model, entity-relationship model, document model, entity-attribute-value model, star schema and object-relational model. Any of these techniques could be used to describe the structure of a database, depending on system specifications. Usually, the database management system is developed around a specific data model, requiring the implementing party to adopt that modeling technique.
(Lucidchart 2021)
Depending on the source of information, different types of data modeling techniques have become intermixed over the years and the clear distinctions between for example object-relational model, entity-relation model and object-oriented model are not always that obvious. In this thesis due to its close ties to object-oriented programming the focus will be on one of the most flexible and known model type of the previously mentioned, the entity-relationship model.
3.2 Entity-relationship model
Like described in the previous paragraph, a vast number of loosely standardized techniques have been developed for data modeling, but by far the most common one is the entity-relationship model originating from 1976. The technique developed by Peter Chen has seen some upgrades over the years but is still a very effective tool. The main elements of the entity-relationship model are entities, attributes, identifiers, and relationships. Entities represent something that is being tracked with a database system and entity instances are occurrences of entities (Picture 4). Entities have attributes which describe the particular entity and identifiers are attributes that identify entity instances.
Entities can be associated with other entities in relationships (Picture 5), which can involve multiple entities. The number of entities in a relationship describe the degree of the relationship. Relationships also have a minimum and maximum cardinality, which are used to describe the number of how many entity instances on both sides of the relationship can occur. (Kroenke & Auer 2013, 221–226.)
Picture 4. Example of an entity and two entity instances.
Picture 5. Example of two entities associated in a relationship.
A common factor across NoSQL database management systems is that they are schemaless. In a relational database management system, you need to define the
structure, model, or schema, in which the data will be stored beforehand. With NoSQL databases there are a lot less restrictions on the structure of the data being stored and a predefined schema is not necessary. Without the restrictions of a schema, the structure of the stored data can be easily changed as new data of interest is discovered which makes it better for handling non-uniform data where each entry might have different properties. (Sadalage & Fowler 2013, 28–29.) While the advantages of a schemaless database system can fuel a quick start for a project without time spent on defining a schema, the lack of planning is usually followed by a lot of afterthought. It is common that patterns are found within the data structures as data volumes grow, and although there is no need for a schema, much of the data might have some schema built in. Even with NoSQL systems a data model enables you to plan the database design before building any application logic and possibly recognize important patterns and implications in advance. A schemaless system implemented without a model is dependent on the developers only to understand the data, which at a later stage can severely restrict non- programmers’ and other stakeholders’ proposals for changes. (Hills 2016, 7–8.)
3.2.1 Crow’s Foot notation
So called Crow’s Foot notation (also known as IE notation) is an easy-to-understand method for describing the cardinality and the nature of entities relationships.
Relationships between entities are presented with lines that can have a text label describing the nature of the relationship, and the cardinality is indicated by symbols on both ends of the line (Picture 6). The symbol closest to the entity indicates the maximum number of occurrences the entity can have in that relationship. The second symbol indicates the minimum number of occurrences which can be zero or more, simultaneously describing the relationship mandatory or optional. (Vertabelo 2016)
Picture 6. Crow's Foot notation cardinality symbols.
Combination of these symbols is used to describe each relationship between entities (Picture 7). A tensile test report entity is associated with a tensile specimen entity in a mandatory-one to mandatory-many relationship meaning that in a context of a database system, a test report instance must be associated with multiple specimen instances and each specimen instance must be associated with a single report instance. The tensile specimen entity is associated with material properties entity in an optional-many to mandatory-one relationship: material properties instance can exist without instances of specimens built from that material, but not the other way around.
Picture 7. Crow's Foot notation example.
3.3 Levels of modeling
Picture 8. Examples of conceptual, logical, and physical data models.
Just like any other design process, data modeling begins from a high level of abstraction and progresses towards more concrete and specific solution (Picture 8). Process will start with a conceptual model, sometimes referred to as a domain model, that will provide a general perspective of the contents of the system and how the content is organized,
and which rules are present. Simplistic conceptual models are usually generated during the analysis of the initial requirements. At the logical modeling level, the goal is to provide greater detail about the data and relationships, without specifying any technical system requirements. One of the data modeling notation systems is used to clarify the relations.
The logical level is frequently omitted in quick data modeling practices. At physical modeling level the data model represents the data as it is physically stored in a database.
As least abstract, physical models offer a system specific design with defined data types and keywords that can be implemented as a database. (IBM 2020)
4 ADDITIVE MANUFACTURING & DMLS
Additive manufacturing (AM), or 3d printing, is a manufacturing process where to form a geometry, material is added instead of subtracted like in conventional machining methods. AM processes have made it possible to design much more complicated geometries or internal structures that would be impossible to fabricate by traditional methods, causing the AM sectors recent rapid growth in manufacturing. Technology is extensively use by global companies such as Alcoa, Audi, BMW, Boeing, General Electric, Stryker etc. The evolution of laser technologies has played a key part especially in metal AM processes, profoundly renewing the methodology of manufacturing in global manufacturing industries including such high standard sectors as aerospace, defense, and energy. (Brandt 2017, 1–4.)
Additive manufacturing technologies originate from the rapid prototyping processes developed in the 1980s. The first patent was filed in May 1980 by Japanese Dr. Kodama, but due to technical and legal issues the full patent specification was not applied before the one-year deadline after application. In 1986, a patent for a stereolithography machine was applied by Chuck Hull, initiating the evolution of 3d processes we see today. Later in 1980s German Hans Langer founded Electro Optical Systems GmbH that became the market leader in metal 3d printing technologies. (Raghavendra etc. 2021, 38.)
Commercially viable additive manufacturing processes are categorized by the European ISO 17296-2:2015 standard to seven different categories; vat photo-polymerization, material jetting, binder jetting, powder bed fusion, material extrusion, directed energy deposition and sheet lamination. The DMLS, or direct metal laser sintering, a trademark process technology of EOS GmbH is categorized as a powder bed fusion process with laser as the source of energy (Bian etc. 2018, 202).
Picture 9. Powder bed fusion process illustration (Bian etc. 2018, 202).
In laser-based powder bed fusion process illustrated in Picture 9, a high-powered laser beam scans the powder bed surface layer inside the printing machine process chamber and melts the powder layer fusing the material either to the build plate or to a previously melted layer. The laser scanning path is derived from a 3d-model geometry provided to the printing machine. After the scanning of the layer is complete, the powder bed is lowered by a predetermined layer thickness and recoated with a fresh layer of powder.
The recoating and laser-scanning process is repeated until each layer of the part is completed. (Brandt 2017, 55.)
Originally additive manufacturing methods were used to produce prototype parts on a rapid schedule. Quality of the AM parts manufactured with early process technologies was nowhere near the quality of parts manufactured with traditional machining methods or injection molding for example. However, the recent development in AM process technologies have improved the quality so much that the focus has shifted towards rapid production. The virtually limitless freedom of design and a wide spectrum of materials have incited the adoption of AM technologies especially in such industries where small batches of complicated components for a very specific purpose are needed.
5 MECHANICAL TESTING OF METALS
Metallic components are used in a wide selection of applications by every major industrial sector - aerospace, automotive, construction, energy, mining and processing just to name some. These components must endure in operation under various and sometimes extreme environmental conditions combined with variable workloads. A plethora of different test methods have been developed, but the most important ones are based on a seemingly simple method of uniaxial loading. With these tests the aim is to experimentally investigate the onset and progression of plastic deformation, and subsequently fracture. (University of Cambridge 2018)
The scope of this thesis clarifies the very basics of a limited set of most widely used mechanical testing methods.
5.1 Tensile strength
Tensile testing is used to determine materials fracture and deformation characteristics under uniaxial tension (ASM International 2004, 13). Tensile properties are measured to ensure quality, compare materials and manufacturing processes and to make predictions of material behavior under different forms of loading. The usual primary goal in tensile testing is to determine either the stress needed to cause plastic deformation or the maximum stress the material can withstand. Another property of interest determined with tensile testing is so called ductility which measures the materials ability to deform before fracture. (ASM International 2004, 1.)
Picture 10. Tensile specimen, as manufactured and as machined.
Typical tensile specimens have enlarged shoulders for gripping and a reduced gauge section where the deformation and eventually failure will happen (Picture 10). Testing machines are either hydraulic or electromechanical universal testers capable of testing materials under compression or tension and plotting so called force-elongation and stress-strain curves (Figure 1). The test itself is conducted by placing the specimen in a testing machine and subjecting it to tension. Tensile force and gauge sections elongation are monitored and recorded as each other’s function during the test. (ASM International 2004, 1–3.)
After the acquisition of force-elongation data the dimension-independent stress-strain curve can be calculated with the help of gauge sections initial cross-section and change in length (ASM International 2004, 3).
Figure 1. Force-elongation and stress-strain curve (ASM International 2004, 4).
It must be made clear that the calculations are only valid if the specimens deformation stays uniform (ASM International 2004, 7). Once the engineering stress reaches its maximum value i.e., so called ultimate tensile strength Rm of the material (Figure 2), the specimen starts to neck: The reduction of cross-section localizes to some part of the gauge section where material is due to some inconsistency weaker than elsewhere. At the neck, the stress increases as the cross-section shrinks until the specimen ruptures.
(Rösler etc. 2007, 70–71.)
Figure 2. Tensile strength, yield strength, young’s modulus (Rösler etc. 2007, 70).
The stress-strain curves initial slope represents the materials young’s modulus E, indicating the materials elasticity and ability to resist plastic deformation. As deformation increases during the test, also the plastic deformation (yielding) gradually starts. Exact limit between elastic and plastic deformation is not possible to determine, but in most engineering applications plastic deformation of 0.2% is assumed tolerable. The stress required for exceeding this deformation called yield strength Rp0.2 is determined by drawing a line parallel to the initial slope of the stress-strain curve at a distance of 0.2%
strain. The lines intersection with the stress-strain curve then determines the yield strength. (Rösler etc. 2007, 69–70.)
5.2 Hardness
Material’s resistance to localized plastic deformation is a measure of hardness (Callister 2000, 134). Rapid indication of materials deformation behavior can be obtained via indentation hardness testing. Depending on the test method used, the procedure is conducted by forcing a small sphere, pyramid, or cone into the test specimen surface with a predetermined force causing plastic deformation. The “hardness value” is then derived from the dimensions of the indentation. Hardness testing produces valuable data especially when information about brittle materials in high temperatures is required.
(Smallman & Bishop 1999, 199.)
5.3 Impact toughness
Impact testing techniques were developed to predict materials fracture behavior and characteristics under different temperatures as certain circumstances could cause normally ductile materials to suddenly fracture with very little plastic deformation. Two test types called Charpy and Izod are used to measure the impact energy. In both test types the conditions were chosen to optimize the potential for fracture: low temperature, high strain rate, triaxial stress state. Also, in both test types the specimen is a square cross-section bar with a V-notch machined to the side. After temperature conditioning the specimen is placed into the testing machine where the test stress is applied by a pendulum hammer released from a fixed height, fracturing the specimen at the notch.
The energy absorption is calculated from the difference between the initial pendulum release height and the height to which the pendulum continues its swing after the impact.
(Callister 2000, 204–205.)
The primary goal of these tests is to determine if the tested material has a clear ductile- to-brittle transition when temperature decreases (Figure 3). Multiple specimens are tested in different temperatures and from each test the measured energy absorption is plotted as a function of temperature. The slope of the curve dictates if there is a clear narrow range in temperature where the material transitions from ductile to brittle.
(Callister 2000, 206–208.)
Figure 3. Absorbed energy-temperature curve (ISO 148-1 2006, 19).
5.4 Creep & Stress rupture
In principle, materials should deform elastically if the stress applied stays below materials yield strength. However, over long periods of time and in high temperatures plastic deformation can occur even if the applied stress stays below this limit. This deformation is known as creep. (University of Cambridge 2019) Creep phenomenon brings multiple serious challenges to engineering and design. The primary concern being whether the manufactured components operating in conditions optimal for creep will endure the required lifespan. Deformation of material or even rupture could render components useless prematurely. (Penny & Marriot 1995, 1–2.)
During creep testing the specimen is placed under constant tensile load, a method that is and has been the most important way of producing creep data since the recognition of the problem in the component design for high temperatures. Data from this seemingly simple and artificial test method will help to predict how varying combinations of temperature and stress will affect the material. From the recorded data properties such as strain over time and time to rupture can be extracted (Figure 4). (Penny & Marriot 1995, 2.) For accuracy of the test results, the temperature maintenance and measurement of dimensional changes during the test must be under special attention as the rise of temperature by few tens of degrees can double the creep strain rate in many materials (Smallman & Bishop 1999, 200).
Figure 4. Strain accumulation during standard creep test (Penny & Marriot 1995, 2).
5.5 Fatigue
The term “fatigue” is used to describe a form of failure that occurs when a material is subjected to fluctuating and dynamic stress levels considerably lower than the materials tensile or yield strength (Callister 2000, 209). The fatigue conditions are usually extremely complex in nature. Failures commonly happen in axles where the loading of a pulley or a wheel produces varying stress levels which peak on the skin of the axle.
Flexure stresses in aircraft wings and undercarriages are another example of the complexity and significance of the phenomenon. (Smallman & Bishop 1999, 253.) Fatigue testing involves subjecting the specimen to constant cycles of stress. Multiple different methods have been developed in which the stress is applied either by bending, torsion, tension or compression. Usually, three main properties dictate the characteristics of the testing method: stress range, mean stress and frequency of the cycles. The standard method of fatigue study is to prepare many identical specimens and to subject them to different ranges of stress. (Smallman & Bishop 1999, 200.) At a relatively large stress range, usually two thirds of the tensile strength, a first series of tests is conducted, and the number of stress cycles each specimen endured before failure is recorded. This process is then repeated on following groups of specimens while progressively decreasing the stress range. The recorded data is then usually plotted as a so-called S- N curve (Figure 5), where the stress level is represented as the function of cycles to failure on logarithmic scale. (Callister 2000, 209.)
Figure 5. S-N curve (ISO 1099 2017, 15).
6 IMPLEMENTATION
Data modeling process began by getting to know the systems currently in development, test types performed and reading through a multitude of test reports to get an idea what the collected data looks like. A huge source of test specific information in conjunction with colleague’s know-how turned out to be the test standards according to which the tests are conducted. Initial idea was to construct the data models only as a Python source code which would be in line with the technical specifications of the internal reporting system in development, but this method quickly turned out to be impractical especially in a situation where input from persons who are not familiar with programming is required.
Alongside of source code, working with Entity-Relationship diagrams provide a much more visual approach to data modeling and enables persons without programming knowledge to comprehend the structures and relations of the data much better. This way input from a bigger audience is much easier to collect and later on the physical code can be based on the entity-relationship diagrams, which simultaneously works as a documentation of the database system.
As data modeling is essentially a documentation process, it must be made clear that every time the application logic utilizing the model changes or some other change in database system takes place, the models evolve accordingly, so the documentation stays up to date. Keeping the documentation up to date requires a lot of manual work prone to errors so the possibility to generate visualization automatically based on the application code should be explored in the future.
There are several commercial and free tools available for data modeling and diagram generation (Lucidcharts, ER/Studio, erwin Data Modeler, Microsoft Visio etc.) but due to its easy utilization and integration with Microsoft Visual Studio Code, a free cross- platform open-source software Diagrams.net was selected to visualize the initial models seen in this work.
6.1 Modeling process
The general workflow in data modeling process is a sequence of tasks that should be performed in an iterative manner. Following three steps make up a rudimentary all- around backbone that can be applied to various data-producing processes.
6.1.1 Conceptual modeling
First step in modeling process visualized by Picture 11 was to figure a conceptual model and define the entity of interest that is wanted to be kept track of and stored in a database. In the scope of this thesis, the entities of interest are the results of mechanical testing of solid test specimens. The conceptual results entity consists of the test results dictated by the test standard used and the test specimen specific identification information.
Picture 11. Modeling process.
6.1.2 Logical modeling
Second step in modeling was to figure the logical models and define the attributes that the test standard entities and the test specimen entity contains. Test standard entities attributes are of course dictated by the test standard according to which the test is conducted, so a logical model from each possible test standard and its key attributes of interests needs to be thought out. As for the test specimen entity, the approach was to build a common model that is applicable to every possible specimen that undergoes mechanical testing. The common model includes information for identification, tracking, and database indexing purposes in conjunction with file specific meta data information if the data is converted from a report file. The standard specific models function as an extension of the common model, meaning that the final results instance stored in the database will be the combination of both models.
The conceptual and logical level of modeling are the levels where input, requirements, and ideas from a wider audience is easiest to gather. At these levels, the modeling takes place on a fairly abstract level and no programming skills or any other database related technical knowledge is necessary.
6.1.3 Physical modeling
The third step in modeling is to build the physical models and define the data types and key names which are largely dictated by the database management system and other technical specifications. At this level the work is in the hands of the developers and system administrators, or other people with the correct kind of technical know-how. At physical level the attributes required by the database management system are added and also the final structure or grouping of certain attributes of the model is defined. For harmonization purposes, it is extremely beneficial to make the models as similar as possible with each other. Similar key naming conventions and structuring makes querying the information from the database much more straightforward.
6.2 Implemented physical data models
The physical models presented in this thesis use JSON-compliant data types, some of which were already seen in picture 3, defined by ECMA-404 2017 standard. (Appendix 1)
6.2.1 Common data model
A diagram of physical common data model can be found in Appendix 2.
As the main objective in mechanical testing is to determine material specific properties, the common data model includes the attributes necessary to identify the specimen unambiguously. This way the specimen and the test results can be linked to a specific material batch of which the specimen was built from in conjunction with manufacturing process parameters and manufacturing equipment information.
For database indexing purposes, the common model contains an _id-attribute field for a database entry specific unique identification number. Additionally, such attributes as any additional notes, reference numbers or identification numbers, date of the test report, name of the test laboratory, or the specifications according to which the test was conducted can be saved under the info-attribute if provided with the test results. As a good example of the flexibility of non-relational database system, only the attribute name under which the possibly provided information gets stored needs to be agreed upon and documented, the format and structure of the data stored under the info-attribute is not restricted in any ways.
Common model also includes information about the purchase order or internal laboratory request made. In the physical model these are grouped under the key-attribute. In conjunction with such attributes as purchase order number, test type and order type information, this group of attributes includes the specimen and specimen packaging specific labeling information dictated by EOS Finland’s internal quality system.
The group of attributes under meta-attribute seen in the physical model are mainly for tracking and debugging purposes. The test report conversion system under development collects the data for these attributes from the original report file.
All the test related data will be distributed under the converted, raw and testParameters attributes, depending on the type of the test conducted. All attributes or variables considered as an input of the test conducted will be stored under testParameters attribute. The numerical result data acquired from each test will be stored under either converted or raw attribute, depending on the unit system in use. The raw attribute is populated only if the data acquired is in imperial units. The test specific models introduced in the next chapter further expand both converted and raw attributes with summary and detailed sub attributes. The summary attribute will contain a summary of test specific key result variables of interest, while the detailed attribute will function as a container for more specific raw data or for example time series data from which the values under summary attribute gets derived from.
As an example, once the system has been properly implemented, the attributes of the models would enable such database queries as gathering every possible test specimen built from a specific powder batch of a specific material for comparison. Further expanding the idea of analytic possibilities, for example generating rudimentary correlation matrices between mechanical properties and chemical composition should be achievable with very little effort once entities such as material batch chemical analysis results are brought into the database system too.
6.2.2 Test specific models
Tensile strength
A diagram of physical tensile strength data model can be found in Appendix 3.
In tensile testing the key test parameters of interest are the temperature at which the test is conducted, the type of the specimen, and the gauge sections geometric dimensions.
On the results side of things, the data of interest includes things such as ultimate tensile strength, yield strength, gauge section elongation, reduction of gauge sections cross- sectional area, maximum force applied, and if available the detailed time series of applied stress vs. strain or applied force vs. elongation. Most of the individual result variables mentioned before could be derived from the stress vs. strain time series. The model for tensile strength test results is based on ISO 6892-1 & ISO 6892-2 standards and acquired test data.
Hardness
A diagram of physical hardness data model can be found in Appendix 4.
As a relatively simplistic testing method, hardness testing parameter of interest is the test standard according to which the test is conducted. Result variables of interest are the standard specified hardness symbol, numerical values of each individual hardness test conducted, and the rounded average of individual tests which is considered as the
“hardness value.” Indentation force application duration is reported only if the duration exceeds 6s, and atmospheric temperature during testing is reported only if it exceeds the range of 10-35°C. The model for hardness test result is based on ISO 6508-1 standard and acquired test data.
Impact toughness
A diagram of physical impact toughness data model can be found in Appendix 5.
As a temperature-sensitive test type, the parameters of interest in impact toughness testing includes both atmospheric temperature and specimen conditioning temperature.
Specimens’ geometric dimensions are largely dictated by the test standard ISO 148-1 according to which the model is built, but exceptions in geometry can occur. Main result variables of interest consist of numerical value of the absorbed energy and a boolean value of whether the specimen disintegrated. The model for impact toughness test result is based on ISO 148-1 standard.
Creep & Stress rupture
A diagram of creep & stress rupture data model can be found in Appendix 6.
Creep testing is a long duration test by nature, where the main result variable of interest is a plastic strain vs. time time-series. Other result variables are numerical values indicating the duration of the test, elongation of the specimen, reduction of the gauge sections cross-sectional area, gauge sections total plastic strain, and time to rupture.
Additional info is collected as boolean value of whether the specimen fractured, and as a string description of the fracture location. Test parameters of interest are specimens’
geometric dimensions, and the stress and temperature at which the test is conducted.
The model for creep & stress rupture test results is based on ASTM E139 standard and acquired test data.
Fatigue
A diagram of fatigue data model can be found in Appendix 7.
As a complicated testing method, fatigue testing includes a multitude of parameters that affects the methodology of the test. A generic collection of fatigue test parameters includes specimens’ geometric dimensions, stress at which the test is conducted, frequency at which the stress cycle is applied, waveform type of the stress applied, temperature at which the test is conducted, a criterion that dictates when the testing is stopped, ratio of the minimum and maximum stress applied, a limit of cycles after which the test should be stopped and in some cases the method used for stress application.
A generic collection of fatigue test result variables includes the information of the specimens’ surface condition, amount of stress cycles applied to the specimen during testing, and amount of stress cycles it took to reach the failure criterion. The model for fatigue test results is based on ASTM E466 standard and acquired test data.
6.2.3 Compliance with standards
Efforts have been made to design the data models according to the test standards used.
Most test standards specify the basic form in which test results should be presented, and it is this information that has been used as a guideline in the design of data models. Key naming in data models has been done as close as possible according to the standards, using a little creativity. In standards, different variables and parameters are usually referenced to with a mathematical-scientific letter-number combination (F0, L0, S0, A, Rp0.2, Rm, etc.), the use of which would require the person reading the data model to know the exact standard-specific variable names. Instead of letter-number combinations, key names are based on the descriptions of the variables.
7 TEST CASE & FUTURE OUTLOOK
7.1 Tensile strength test case
During the writing process of this thesis, the tensile strength data model described in Appendix 3 has been successfully utilized in a prototype database environment under development. Tensile strength results from a single chosen test provider arrive as an Excel spreadsheet as depicted in Picture 12. This data is then supplied to a conversion script that generates a JSON-formatted document where each row of the spreadsheet is represented as a JSON-object depicted in Picture 13, defined by the tensile strength data model. The generated JSON-formatted document is then inserted into a database.
Picture 12. Tensile strength results in Excel spreadsheet
It should be noted that this process is far from optimal. There are multiple unnecessary stages where the data of interest is converted from one format to another and possibly even manually copied between documents and applications, making it possible for the data to become corrupt or degraded. A preferable process would be that the data generated by the tensile strength testing equipment would initially be in such format that it would be possible to store to the database as-is, possibly even structured in a way described by the data model.
Picture 13. Tensile strength result as a JSON-object.
7.2 Plans for legacy data
The company has a very large number of various test results from various projects stored in project folders. In order to utilize the already acquired data in a wider context i.e., for analytic purposes, it is essential to convert the so-called legacy data into new data models and store them in a database for much more convenient access. Though this subject is a bit outside the scope of this thesis, it has been an ongoing project during the writing process, and for this reason the subject will be briefly discussed here.
The way data is transferred from external laboratories to company data storage and analysis systems should be streamlined. Currently test data is mainly arriving as email- attachments, and then stored to individual project folders on a network drive. A direct data exchange method between company and laboratories database systems would be an ideal addition. As the company digitalization initiative progresses, new technologies including cloud-based solutions are becoming available, which should be properly explored and assessed for this purpose.
7.2.1 Automatic conversion
Given the fact that there is little consistency in some test reports, developing an automatic conversion tool for every possible test type is extremely laborious and challenging. In addition, most reports only exist as PDF documents, which, if read with a machine vision or character recognition system, for example, would likely produce corrupt data. This is a problem especially in such cases where the PDF document has been scanned from a paper document. In addition, the data generated by the machine vision or character recognition system should in any case be manually entered into the new data models, as there is no guarantee that the reports will be consistent. Reading Excel-formatted reports i.e., with Python programming language utilizing the Pandas data analysis library is fairly straightforward, but once again the inconsistency makes automatic conversion almost impossible: If cells, rows, columns and variable names do not stay the same from report to report, there is no point in developing an automatic conversion tool.
However, if in collaboration with the laboratory producing the test data, it is possible to define a fixed format in which the data is delivered, it is relatively simple to create an
automatic conversion system. It remains to be seen whether laboratories are willing to provide test data in a fixed format retrospectively. And even as a short-term low-tech solution it would be beneficial if the laboratories are willing to implement some sort of fixed spreadsheet-template for data exchange while more convenient solutions are under development.
7.2.2 Manual conversion
Manually entering existing test results into conversion tools could be a sensible approach to converting at least a part of the legacy data. Tools for conversion are likely to be easier to implement based on data models created per test type.
One operating model could be to build a web-based reporting system utilizing the framework of the internal database portal already in development. Reporting system could create a dynamic report template to be populated based on the developed data models. The conversion process itself is more laborious in this approach and data corruption is possible due to human error, but changes in the format of the reports are much easier to deal with.
Other, even more manual method would be to just take the time and collect and clean the data that is considered most important to a tabular format, and manually convert it in a few batches. Conversion scripts are fairly straightforward to develop if the data cleanup is done properly, and this way there is no need to develop tools that would possibly require updating and maintenance in the future.
8 CONCLUSION
As the whole digitalization initiative and the utilization of a database system for test results is in its early steps, the data models described in this thesis should be considered as initial sketches bound to be improved as the system development progresses forwards. The models are refined enough to be utilized in the prototype stages of system development to collect feedback and to improve the models accordingly, but the final implications are near impossible to assess without a longer testing period.
Though abstract by nature, data modeling and the construction of visual representations of data systems are powerful tools, especially when working with people who are unfamiliar with programming or database development in general. The precise definition of the method or technique used to create the models should not be the primary concern, but rather the methods should be defined so that all stakeholders involved can understand what is the focus of the process and contribute as the process progresses.
Construction of a data model is not necessary when implementing a document-based non-relational database system, but the value of properly formatted documentation is something that is proven to be extremely important especially as systems expand and get more and more complicated. A data storage system implemented without documentation could be considered as a “hostage” of the developers if the only party with proper knowledge of the construction and relations of data is the developers themselves.
The scope of this thesis was limited to a narrow selection of data-producing processes to achieve a proof-of-concept kind of result and documentation about the data modeling process. Same principles of data modeling can be transferred to any other data- producing tests and processes in the future. Process described in the previous chapter and systematically progressing from conceptual to physical model, iterating, and asking for feedback at any given stage is a good guideline to achieve functional models.
REFERENCES
ASM International. 2004. Tensile testing. Second edition. Materials Park OH: ASM International.
Beaulieu, A. 2020. Learning SQL – Generate, manipulate and retrieve data. Third edition.
Sebastopol CA: O’Reilly Media Inc.
Bian, L.; Shamsaei, N.S. & Usher, J.M. 2018. Laser-Baser Additive Manufacturing of Metal Parts.
Boca Raton FL: Taylor & Francis Group.
Bierer, D. 2020. Learn MongoDB 4.x. Birmingham: Packt Publishing Ltd.
Brandt, M. 2017. Laser Additive Manufacturing. Materials, Design, Technologies and Applications. Duxford: Woodhead Publishing.
Callister, W.D. 2000. Materials Science and Engineering, an Introduction. Fifth edition. New York:
John Wiley & Sons Inc.
ECMA-404. 2017. The JSON Data Interchange Syntax. Second edition. Geneva: ECMA International.
Educative 2020. What are database schemas? 5 minute guide with examples. Referenced 16.9.2021. https://www.educative.io/blog/what-are-database-schemas-examples
Hills, T. 2016. NoSQL and SQL Data Modeling. Bringing Together Data, Semantics, and Software. Basking Ridge NJ: Technics Publications.
IBM Cloud Education 2020. IBM Cloud Learn Hub. What is Data Modeling. Referenced 29.7.2021.
https://www.ibm.com/cloud/learn/data-modeling
ISO 148-1. 2016. Metallic materials – Charpy pendulum impact test. Third edition. Geneva:
International Organization for Standardization.
ISO 17296-2. 2015. Additive manufacturing — General principles — Part 2: Overview of process categories and feedstock. Geneva: International Organization for Standardization.
ISO 1099. 2017. Metallic materials – Fatigue testing – Axial Force-controlled method. Third edition. Geneva: International Organization for Standardization.
ISO 6508-1. 2005. Metallic materials – Rockwell hardness test. Second edition. Geneva:
International Organization for Standardization.
Kroenke, D. & Auer, D. 2013. Database Concepts. Sixth edition. Upper Saddle River NJ: Pearson Education Inc.
Lucidchart 2021. What is a Database Model. Referenced 16.9.2021.
https://www.lucidchart.com/pages/database-diagram/database-models
Oracle 2021. What Is a Database? Database defined. Referenced 29.7.2021.
https://www.oracle.com/database/what-is-database/
Penny, R. & Marriot, D. 1995. Design for creep. Second edition. Dordrecht: Springer Science+Business Media.
Raghavendra, K.; Manjaiah, M.; Balashanmugam, N. & Davim, P.J. 2021. Additive Manufacturing.
A Tool for Industrial Revolution 4.0. Duxford: Woodhead Publishing.
Rösler, J.; Harders, H. & Bäker, M. 2007. Mechanical Behaviour of Engineering Materials.
Heidelberg: Springer-Verlag.
Sadalage, P. & Fowler, M. 2013. NoSQL Distilled: a brief guide to the emerging world of polylglot persistence. Upper Saddle River NJ: Pearson Education Inc.
Simsion, G. & Witt, G. 2005. Data Modeling Essentials. Third edition. San Francisco CA: Morgan Kauffmann Publishers.
Smallman, R.E. & Bishop, R.J. 1999. Modern Physical Metallurgy & Materials Engineering. Sixth Edition. Oxford: Butterworth-Heinemann.
University of Cambridge 2019. Creep Deformation of Metals. Referenced 21.7.2021.
https://www.doitpoms.ac.uk/tlplib/creep/
University of Cambridge 2018. Mechanical Testing of Metals. Referenced 20.7.2021.
https://www.doitpoms.ac.uk/tlplib/mechanical_testing_metals/
Vertabelo 2016. Design Fundamentals. Crow’s Foot Notation. Referenced 5.8.2021.
https://vertabelo.com/blog/crow-s-foot-notation/
Watt, A. & Eng, N. 2014. Database Design. Second edition. Victoria BC: BCCampus.
Zhu, W.D.; Gupta, M.; Kumar, V.; Perepa, S.; Sathi, A. & Statchuck, C. 2014. Building Big Data and Analytics Solutions in the Cloud. First Edition. Armonk NY: International Business Machines Corporation.
Appendix 1, JSON data types
• object
“An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs. A name is a string. A single colon token follows each name, separating the name from the value. A single comma token separates a value from a following name. The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.” (ECMA 2017, 3)
• array
“An array structure is a pair of square bracket tokens surrounding zero or more values. The values are separated by commas. The JSON syntax does not define any specific meaning to the ordering of the values. However, the JSON array structure is often used in situations where there is some semantics to the ordering”
(ECMA 2017, 3)
• number
“A number is a sequence of decimal digits with no superfluous leading zero. It may have a preceding minus sign (U+002D). It may have a fractional part prefixed by a decimal point (U+002E). It may have an exponent, prefixed by e (U+0065) or E (U+0045) and optionally + (U+002B) or – (U+002D). The digits are the code points U+0030 through U+0039.” (ECMA 2017, 3)
• string
“A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F.” (ECMA 2017, 4)
• true / false
• null
