ISA-95 as the Ontology of Automotive Operations

Automotive is one of the most complex forms of manufacturing around. The product is an intricate assembly of components and subcomponents. Its planning requires intense coordination of global supply chains. Its exection requires efficient sequencing of processes. And its orders must comply with rigorous safety and testing standards at every node of production.

For large, multi-national OEMs, coordinating this production across multiple sites requires a model of production that is flexible enough to encompass all the details of the business. Standardization of production across sites, forecasting and analysis, and supply chain logistics are all problems that necessarily require data communication between sites, teams, and responsibilities. At scale, the only model that can adequately encompass the complexity and interconnection of the automotive operation is an ontology.

A manufacturing ontology provides a semantic layer to integrate data in different formats, coordinate event messages between machines, and serve as the system of record for the resources and events of an operation. However, because of the heterogeneous landscape of specialized applications and the differences in vocabulary and goals between different teams, an automotive ontology would be extraordinarily difficult to build from scratch. Fortunately, one already exists: ISA-95.

With a sufficiently flexible and powerful model, such as Rhize’s ontology based on ISA-95, the model is pre-built. Note that the model does not determine production but describes what already exists. As the periodic table provides a vocabulary for any atomic configuration, ISA-95 provides a vocabulary to describe all existing and future use cases in a standard model. Its application results in standardized data storage and exchange across systems and responsibilities.

This article looks at some of the most important manufacturing operations use cases in the automotive industry and explains how these use cases are described by the language of ISA-95. As always, these use cases “stack”, so each incremental implementation requires less work while providing ever greater context for deep analytical mining.

The interrelationship between resources and events

Before diving into use cases in detail, consider how much information is required to model just the activity implied by this diagram of an automotive plant floor.

Layout of auto-assembly plant. https://link.springer.com/book/10.1007/978-94-007-7593-0 — Source: *Operations Management in Automotive Industries,* by Marco Gobetto.

To translate this diagram to ISA-95, each area is role-based equipment. Each area has a defined role, such as pressing. Material like “sheet metal” and “minor body parts” flow through different equipment areas and are consumed in the course of production as new material is made. Each process has a model with required material, equipment, and personnel. These processes are linked through workflows and dependencies that configure the necessary sequence. The more digitized a plant is, the more data will exist for each job definition, schedule, and execution.

With ISA-95, all processes have a standard language, and all entities and events are linked through their relationships.

Use cases in depth

Now let’s look at some specific use cases in the automotive industry and discuss how they are described by ISA-95.

Process definitions and dependencies

Customization is a major part of consumer demand for autos. Yet outsiders to the industry are often surprised by the amount of variation that occurs for each produced unit, even units of the same make and model. The process to make a car is a process that contains many other processes (and sub-processes, and sub-sub-processes…). While some base processes are shared across jobs, small tweaks across orders are a part of the industry. Unlike other forms of discrete manufacturing, where identical products maybe directed by one order, automotive orders are often related to a single unit. Furthermore, the processes exist in a vast web of dependencies: some steps cannot be executed before others are. For all these reasons, definition management is a critical use case for the automotive industry.

For an example of where definition management is critical, consider the many definitions required when using DC torque tools (also known as transducerized tools). Every screw fastened in an automobile requires a precise torque. The procedure for each fastening typically must follow a defined workflow. Incorrect procedures are safety failures.

The DC torque tools are themselves programmed with definitions to ensure precision. The data exchange requires high-connectivity to download definitions before they happen and send results after they happen. Over the course of the production of an automobile, DC torque tooling may happen thousands of times.

ISA-95’s definition entities provide a rich model to capture each of these jobs across the entire assembly. Each definition entity specifies the necessary material, personnel, equipment, and physical assets required.

Here are some ways that specific definition entities may be implemented for DC tooling.

The repeatable instructions for one order are encoded in a work master. To ensure correctness, these instructions may be downloaded by the DC torque tool (or the system that communicates to the tool).
Job-specific overrides are encoded in a work directive, which clones the work master at the time of production and adds the specific customizations.
A sequence of jobs and their dependencies are encoded in the workflow specification (where each work master is a node)
Finally, the jobs may be aggregated for analytics and high-level scheduling in a process segment.

For examples of how these models formally relate, read the Rhize guide to Work Definitions.

Testing

To continue with our example of DC torque tooling, the safety requirements of the automotive industry require that each torque fastening job is checked. Typically, these checks are done by automated processes.

When a torque job is finished, the testing assets may execute a test job. Since Quality is just a category of manufacturing operations, like Production, the same same test template that you use to define the definitions of a production torque job can also be used to define a test.

Once the test executes, the results are in a test job response. Along with test data, which may include measurements and computer vision checks, the test job response also likely includes information about the specific material lot checked and the test station where the test was located―an example of shared information across models and links in the ontological knowledge graph.

Track and trace and genealogy

Tracking material as it flows across the production line is a critical function for automotive OEMs. In the worst case, product recalls can only be controlled with detailed genealogical records and job reports. But the visibility and control is of great value for day-to-day operations as well. Track and trace and genealogy provide ways to ensure that material is being consumed for the correct jobs, at the correct time, and location.

The ISA-95 model has a complete vocabulary to describe all information required of a genealogy or track and trace. A material lot, such as a fully assembled car, is assembled from material sublots, such as the body, axle, and chassis. This assembled from relationship is formally defined in the ISA-95 ontology, so to determine the forward or backward genealogy of any component (say a chassis and the parts that went into it, or the reverse) is a matter of a query.

Track and trace generally is a collection of job reports, which follow what was used and consumed along jobs along the assembly line. For general examples of how ISA-95 can capture these use cases, you can visit our use case guides on genealogy and EBR.

A walk through the activity model.

ISA-95 provides a model of the major activities of manufacturing operations management. Taken together, this model also provides a guide to linking data flows and representations from different responsibilities.

Each component of the activity model has many use cases in the automotive industry:

Definition management. The automotive industry is full of problems where processes and their dependencies need to be defined. These are often depicted visually in product layouts and material flows.

The DC tooling example described in the previous section is one instance where definition management is critical. Definition dependencies may also be involved for triggering maintenance jobs.

Definitions often involve data from other systems, such as product data management systems, or the BOMs in ERPs.
Capacity management. Determining the capacity of a site or work unit to execute a certain set of processes is critical to not over-scheduling and creating excess product, or underscheduling and leaving the plant running below capacity.

In the automotive industry, this includes the obvious physical constraints of the equipment at the site, but it also may involve more specialized configuration for local laws and labor regulations. For example, the use case of man power planning involves the personnel entity, and this entity may have associated entities related to its capabilities, such as certifications and available working hours. One step up, the work center or site may also have work calendar entities.

From the integration side, capacity management may incorporate data from the ERP and WMS systems.

Scheduling requires the use of the definition management and capability models to plan accordingly. Detailed scheduling also requires carefully understanding process dependencies so that excess buffers of intermediate parts are not created.

Scheduling and planning are particularly complex jobs in the automotive industries, one that may incorporate data from ERPs, WMS systems, and PLMs. While a single automobile represents an order, this order is going to be made up of child orders, all of which have their own material, equipment, and personnel requirements.

Returning to the example of operator capabilities, when an order is assigned to an operator, the scheduling logic must check that the operator has the appropriate certifications. This action requires not just a scheduling model, but also definition entities for the job, resource entities for the personnel, and personnel capabilities to encode the certification information.

Dispatch. Refers to the execution of a job at hand. Dispatch is where an OEM can plan production with the highest level of efficiency, since it allows for just-in-time changes to production planned on a designated work center. The dispatch functionality may incorporate data like work alerts that were emitted prior to processing the latest job order.
Execution management. Execution management ensures the right line is always performing the right work on the right material lot. Execution management incorporates all the resources and processes defined and planned in early steps. The jobs are recorded in data management systems.
Data collection. Recording the process of execution management for storage, analysis, and quality checks. Later steps in a process rely on the data collection to dispatch jobs.
Tracking. Recording records of all work done. The track and trace and genealogy use cases described in the previous sections are classic examples of tracking use cases.

Analysis. In the final step, OEMs can use ISA-95 models to determine information like what lines are most productive, where dysfunction is happening, how much work was done vs. how much was planned, and so on.

Analytics use cases may include equipment utilization analysis and labor efficiency analysis.

To summarize, every activity in the activity model is related, either directly or indirectly, to the entities required for other entities. Using ISA-95 ensures that automotive makers have a coherent, connected model across the operational phases. The activity model also provides a framework for high quality data for machine learning and other AI applications.

The master model

ISA-95 is the language to encompass all manufacturing operations, and the automotive industry is an industry where all types of operations happen. For its scope and complexity, it makes a particularly good candidate to adopt ISA-95.

Everything in an ISA-95 model is connected. You can use the abstract models to track how specific instances of different classes and models work. For multi-site operations, where similar makes and models may be assembled across multiple sites (given changes for local regulations and standards), a connected model that allows for infinite variation at the details provides the only way to create a unified, digital model of the entire operation.

Rhize is, by the way, the only company in the world that offers this full model. And it also executes logic to replace and extend current MES systems. If you’re considering the migration from SAP ME and MII, for example, Rhize is the ideal candidate.