Evolution to Semantic Model-Based Operational Integration

Over the past many years, a number of architectural approaches have been defined for the integration of systems and the representation of their information and processes. These approaches include data-oriented, message-oriented, service-oriented, and information-oriented approaches. The questions to be explored are:

• How are these different approaches different and related?
• From the perspective of real-time operation integration architecture, where is the semantic model suitable for use?
• What value can a semantic model provide as a key component of an integrated architecture for real-time operations?

1. Centralized Application Data

From 1950 to 1980, monolithic applications required the application to own all the data. All access to data is local; all definitions, relationships, and knowledge are contained within the application. Departmentalized users in the enterprise have direct domain knowledge, so no integration is required.

Complex applications and systems have steadily increased in complexity as computers have become more affordable and proliferated throughout industrial operations, and programmable logic controllers (PLCs) and embedded computing capabilities are included in end devices. From 1990 to the present, database and client-server architectures were and still are used to allow multiple concurrent clients to interact with a centralized data store.

With centralized data storage, the centralized application owns some of its data, and other applications call directly to obtain information or to request that the called application perform some action. Historically, this involved calling another application directly through an application programming interface (API) or remote function calls (RFCs). The API and RFCs are contained in the client library, which the calling application links against. In this case, the calling application is responsible for understanding the semantics of the called application and is responsible for all data conversion, etc. While fast from a performance perspective, this approach has proven to be expensive (and brittle) from a maintenance perspective, since a failure in one application can have knock-on effects for all directly interconnected applications ). Furthermore, data validation methods are poorly documented in most cases. Thus, new requirements of new consumers of basic data lead to the deployment of parallel systems to capture additional data while introducing alternative data validation rules. This practice produces multiple "versions of the truth", so all users of the data spend 50-75% of their time reconciling and validating the data before they can trust the data enough for analysis. This lead time increases as system complexity and point-to-point integration increases. Another benefit of semantic computing is reducing this wasted time.

1. Data-Centric Architecture

The alternative to centralized applications that own data is a data-centric architecture. This is clearly a step forward from the direct-connect approach, as applications won't connect directly to each other to exchange information. A data-centric architecture is based on a single definition of related business and operational data around which systems are integrated and applications are developed. In short, a data-centric architecture establishes a common data model for a centralized data store and the rules and requirements for interoperating client applications using that centralized data store. Unfortunately, the data is replicated from their endpoints in various SORs, where unique validation rules are applied. This also resulted in multiple "true versions".

An early example of this approach was an early version of SAP. These SAP releases are (or at least appear to be) basically suites of 40+ applications developed to interact around a central data model. While SAP supports other integration methods for external applications, SAP has adopted a data-centric approach for inter-application communication, resulting in data duplication.

Integration methods prior to XML, while inherently simple, were implemented with fixed data structures, resulting in a rather tightly coupled system in which all system components were affected by changes in data and data structures. This architectural approach often results in a single point of failure in the shared data store. It's not historically critical in business systems, but in real-time workflow applications in operations, this approach breaks operational systems. And cause huge efficiency and quality loss and additional cost.

1. Data for Distributed Applications

With the advancement of the web from 1990 to the present, the complexity of applications has grown into distributed systems built from multiple communicating (integrated) applications. While early implementations were mostly attempts to break out of monolithic architectures, they were still based on a monolithic application model and designed for specific domains.

Ultimately, this leads to a new class of systems in which multiple applications are integrated to create new functionality and use the data contained within each application to achieve functionality not originally intended by the original application designers. In this case, each application is a SOR—an information system that is the authoritative data source for a given data element or piece of information.

The problems caused by the distributed nature of these systems quickly led to the realization that distributed architectures are hard and brittle. A better way of communicating between systems is needed to handle communication failures and application availability issues. This led to the idea of ​​a loosely coupled message-oriented architecture.

1. Message Oriented Architecture (MOA)

A Message Oriented Architecture (MOA) is used to exchange information (documents) where there are no implicit semantics about what should be done with received documents.

What does this definition mean? This basically means that MOA is used for broad information sharing. An example is stock quotes, where a financial services company has a MOA backbone (for example, TIBCO, MQ, or MSMQ) to distribute changes in stock value to any interested applications. The MOA doesn't dictate what someone does when they know the value of the stock has changed; the MOA just notifies them that this has happened. According to this definition, MOA is mainly used for data synchronization and event notification. Therefore, MOA is usually publish/subscribe based.

By itself, MOA does not involve any data model for exchanging information. It moves data from point A to point B with the requested quality of service. It does not define the content, nor does it capture the semantics of the system.

The MOA can be extended to include structured data when the MOA expects a response. In this case, the data model of the information to be exchanged is usually based on industry standards. Examples include EDI (Electronic Data Interchange), BEMML (an XML implementation of the ISA-95 standard), and BatchML (an XML implementation of the ISA-88 standard). The data model used can also be used for the data model we discussed in the "Data Centric Architecture" section above.

1. Service Oriented Architecture (SOA)

While MOA helps alleviate the complexity of communication between applications in a distributed system, typical systems are built with point-to-point integration where information semantics are hidden, hidden in the implementation and simply not available at runtime.

SOA adds a standardized approach to interoperability between applications or application components. SOA adds a platform-independent description of interface contracts discoverable at runtime. This enables casual clients to access exposed information, which is sometimes impossible in MOA without deep knowledge of the data being exchanged and the structure of the messaging backbone. Unfortunately, not all the information was made public, but the concept does offer a degree of improvement. With rigorous design and governance oversight, the extent of improvement is substantial.

In SOA, consumers (clients) interact with providers for some well-defined purpose (for example, to process an order). Information is task-specific and does not change frequently. When the information does change, a new service is added to maintain "backwards compatibility" with existing systems. A single service definition captures the semantics of the service and its data, but cannot provide any knowledge about the system.

1. Information Oriented Architecture (IOA)

Due to the diversity of infrastructure, the previous architectural approaches can be said to complement each other, and it makes sense to use them together in practice. In fact, any evolving architecture must provide a way to effectively coexist and/or integrate with existing systems. Systems need to evolve, and refactoring is simply not affordable or realistic. IOA extends SOA to include canonical views and access to information in integrated systems as the basis for business and operational intelligence and analytics, supporting process optimization and enhanced decision making. IOA provides the market with a basis for composing business and operational processes that together create composite applications around a single information model. The model defines the canonical form of data exchange and defines the specification of data mediation. This differs from the data-centric approach above in that the canonical model is the exchange model, not necessarily the model of any given service. The challenge is that the data model is designed for a given set of problems. Redirecting it for other purposes requires SOA-like governance rules and processes.

Semantic computing, on the other hand, defines data at the element level, so models for specific purposes can be easily created without moving data from appropriate data stores. Semantic computing is not suitable for all applications, but many are unique. Some key examples are (1) strong, agile governance, (2) real-time HAZOPs, and (3) data management throughout the design, procurement, construction, handover, start-up and commissioning phases, and operation and maintenance phases. Given that these example solutions target a relatively small set of people and a focused set of long-running functions and tasks, the usual scalability challenges are not an issue with Semantic Computing.

IOA typically includes MDM (Master Data Management) and BI and OI tools as a complement to SOA. In his data integration blog post ( dataintegrationblog.com ), Robin Bloor points out that IOAs may also contain semantic data mappings to provide context for information to be accessed within MDM and integration applications. This idea is consistent with the basic premise of this paper. No matter how useful the architectural approaches described earlier have proven, they lack context for processing information. SOA, combined with standards-based messaging such as OAGIS, BAMML, and BATCHML, provides the ability to create and integrate composite processes and applications for services such as order management or production tracking. However, there is still no override context for the information that a client application can request.

This context is provided in the IOA by a real-world overlay model that provides context for information requests. In this way, requests (and associated services, definitions of data, etc.) are associated with objects in the model that define their meaning and provide their context. For example, an industrial enterprise can be modeled based on industry standards such as ISA-95 and ISA-88 to define an enterprise hierarchy for oil rigs. This model is at the lowest level of the hierarchy and contains instances of equipment resources such as pumps or motors associated with information requests, actions, and responses. This association then provides context to support queries such as "find available work orders for this pump", "report the current temperature of this motor", or "calculate the pH average for this tank for the last week". By adding context to IOAs, IOAs behave like semantic computations. In fact, ISO 15926, Industrial automation systems and integration – Integration of lifecycle data for process plants, including oil and gas production facilities, is one such standard definition.

All this information can be obtained in one way or another by any of the previously described architectures. What semantic computing does is bring provider-independent context, rules, and ongoing governance into the discussion in a way that is meaningful to industrial enterprises. Semantic computing simplifies the task of accessing data and associating meaningful actions with events related to modeled objects.

1. Model Driven Architecture

The discussion so far has focused on the use of semantic models to support operational systems integration and, arguably, through the use of SOA, middleware, semantic computing and (where appropriate) common information models to create composite/integrated applications. In semantic computing, multiple information models can be constructed for specific needs, thereby eliminating the need for a fixed general information model. This may sound similar to the model-driven architecture discussed earlier, but in reality, it is very different. Model-driven architecture, explained in detail in Alan Brown's paper "An Introduction to Model-Driven Architecture", is about using process models in the context of application design to drive the development of an application, possibly including the generation of the application code itself. In contrast, this paper's discussion focuses on the ad-hoc or centralized use of the model, combined with SOA and appropriate middleware, to act on information provided in context, focusing on information available in the enterprise and independent of the SOR.

Information model - the heart of the semantic model

The term information model (IM) is often used for models of individual things, such as facilities, buildings, and process plants. An information model formalizes a description of the problem domain without constraining how that description maps to an actual implementation in software. In short, an information model is a way of abstracting different data. An information model is about describing what data means (ontologies) and where they fit. In the context of semantic computing, these data can be organized to answer any specific question. Today, vendors typically use semantic computing concepts to solve specific, predefined problems in a limited set of views. An information model allows us to understand and abstract knowledge of its design intent.

ISA-95 is a good example of a domain-specific information model designed to optimize the operations of industrial facilities by addressing the four operational activities described above (see "The Complexity Problem in Manufacturing"). The ISA-95 standard correctly states that its model structure does not reflect a specific business organizational structure within a company, but rather a model of operational activities. Different companies assign responsibility for activities or sub-activities (functions and tasks) to different business organization groups. In other words, ISA-95 defines instances of data/objects and activities in the Manufacturing Operations Management (MOM) domain. The ISA-95 activities do not specify which systems must be in place or how these systems should be implemented or integrated. Information models help us understand how different pieces of information relate to each other, but not how a system should be implemented.

ISO 15926 Industrial automation systems and integration - Integration of process plant lifecycle data, including oil and gas production facilities, is another example of equipment lifecycle information management, from concept to preliminary engineering, detailed engineering, procurement, construction, handover , and then to the operation and maintenance (O&M) phase, ISA-95 is also applicable. ISA-95 complements the Operations and Maintenance phase of ISO 15926, serving as the engineering management of the change database, keeping knowledge of all equipment and system configurations consistent. This consistency management is assumed by ISA-95, but it is definitely outside the scope of ISA-95.

A semantic model is a specific information model. Semantic models help identify patterns and trends in information and discover relationships between different pieces of information. The semantic model uses two important structures:

• Vocabulary: A set of concepts given a well-defined meaning, consistent in context.
• Ontology: Defining the contextual relationship behind vocabulary is the cornerstone of defining a specific domain of knowledge.

A semantic model consists of a network of concepts and the relationships between those concepts. In an industrial enterprise, the concept might be "production request", "batch" or "equipment". ISA-95 Part 1 is a good example of a semantic vocabulary, defining well-understood domain-specific concepts.

The meaning of a concept is defined by its relationship to other concepts. A good example of this relationship in ISA-95 is DeviceClass and Device. Since devices are semantically associated with device classes, systems and people in the domain can use semantic relationships to find all devices of a particular class.

Although there is no formal relational standard, semantic models typically use the following definitions:

• Instance: x3456 is an instance of a batch.
• IS_A: A reactor is a type of equipment.
• HAS_PART: Reactor <has part> heater.

As knowledge changes, semantic models must evolve. For example, when defining a new operation definition (product) segment, it may be necessary to change the information model by linking it to a specific operation/process segment. Additional qualitative data relevant to the operating sector can be fed into continuously updated models, enriching knowledge of patterns and impacts.

In the concept of semantic computing, such changes are "discoverable" and automatically embedded in the infrastructure.

course of action

The main goal of information modeling is to provide an agile, adaptable, and easy-to-understand methodology and terminology for accessing data and context within SORs to enrich knowledge and improve the adaptability and responsiveness of each organization.

An important element of information context is its context, the ordered history of information changes. This is especially critical in many analytical applications. Context helps answer questions such as:

• What batch of material was used for this batch?
• When did we hear about it?
• Why did you make such a decision?

Context adds important context, connecting instances to a timeline of events and activities. The context also provides information about the duration of process execution, whether related to equipment, material transitions, system performance, or people's ability to respond. For example, an ideal system would capture data during the following time periods:

1. Creation within any SOR (enter a request to manufacture a product).
2. Submitted to the operator as a task (tells the operator to make the product).
3. A status change from the device, indicating that the process has started (the product is now being manufactured).

In this example, the context provides live measurements of process performance and all participants.

Since changes occur in multiple distributed systems, no single SOR contains a complete history of changes. Every SOR provides every piece of its puzzle in the form of historical data. Because of this, we often only see an incomplete and incomprehensible picture of what happened in the past. No single SOR will provide complete contextual coverage and visibility of all SORs involved in the execution of manufacturing operations. Semantic computing allows these items to be linked without changing any pre-existing SOR.

Complexity of business data

Unfortunately, most of the data that exists in the various SORs within a manufacturing enterprise is not in a nice, flat, table-like format. Data often takes the form of an ugly mess of complex structures, hierarchies, sets, and arrays. While computers can easily process it, humans cannot easily understand such information. To make matters worse, most reporting and BI tools on the market today are designed to handle flat, table-like data sources. Semantic computing simplifies this problem. It is recommended to place a wrapper around each SOR to expose the underlying data for common access. This approach keeps the SOR "as is" while providing broader access to the data to improve business performance.

For example, the OPC standard defines different specifications for data access, alarms, events, complex data, historical data, etc., each with its own information model to capture and provide the context important to the intended use. Even a simple simulation item, such as a pressure sensor, is an object with properties and references to multiple other objects (Figure 2-3). These objects provide potentially important information, such as instrument range or engineering units.

Figure 2-3: OPC UA Analog Item Representation

Taking the object defined by ISA 95 again as an example, we can see that although the device capability (Figure 2-4) is a complex object that contains a set of device capability attributes, only a few of them may be needed for a query at any time . Additionally, each device capability attribute is itself a complex object with multiple data elements.

Figure 2-4: ISA-95 Operational Capability Model

Semantic modeling helps define these structures by providing users with information and the tools to extract the required information. It is easy to imagine a user or system querying all device capability attributes of a "capability" by selecting the "value" and "unit of measure of value" attributes of the "device name" and device capability attributes.

Historically, all data has been accessed through a single or multiple transactions with the SOR, depending on the underlying implementation technology. The format of the data ranges from XML documents (B2MML, BatchML) and binary objects (OPC, Tibco, MSMQ) to Web URIs (a generic version of URLs), and everything in between. Establishing communication with these data sources is not enough; the application-specific format must be translated into a common, standards-based format that is easily understood and usable by all customers. Without the vocabulary provided by the models and related industry standards, this knowledge is locked in the source SOR.

OPC now provides semantic access to and various operations on data, such as semantic determination of average, minimum, and maximum values ​​within a specified time range.

semantic model

This section details examples of how Semantic Models are deployed on Model Servers (see "Model Servers" below).

Semantic computing, as defined by the World Wide Web Consortium (W3C), "provides a common framework that enables data to be shared and reused across application, enterprise, and community boundaries." While the definition of the World Wide Web is usually about the ability to share documents, semantic computing provides a framework so that individual data elements can be shared and more easily understood by machines. Semantic computing can support the notion of a common format for data presented from a variety of different sources. It also provides structure for understanding data relationships. This enables requests for semantically based web data rather than relying on explicit (or implicit) links or references.

The Semantic Computing Architecture, defined by Tim Berners-Lee, is a hierarchical structure with an XML base for namespace and schema definitions to support a common syntax. The next layer on top of XML supports Resource Definition Framework and RDF Schema. RDF is a framework for graphical representation of resources. Although it was created to represent information about web resources, it can be used for a variety of other data types. The core definition of RDF elements is based on triples of the subject-verb-object form. The machine-readable format of RDF is XML (RDF/XML).

An RDF model essentially defines a graph described by triples. RDF Schema (aka RDF Lexical Description Language) provides RDF with additional knowledge such as terms that can be used, restrictions that apply, and other relationships that can exist. RDF schemas can be created to describe taxonomy of classes (as opposed to resources in RDF) and formalized relationships between resources (types and subclasses) to define simple ontologies. More complex ontologies can be created using the Web Ontology Language. Ontology vocabularies are the next layer in the semantic computing architecture.

As mentioned earlier, an ontology provides an understanding of concepts (terms and relationships) within a domain through a defined vocabulary and a taxonomy of models. In a specific industry domain, an ontology can be used to support multiple applications. Additionally, an ontology can be created to support generally applicable terms and relationships that can span multiple domains. Ontologies define entities and relationships to represent knowledge that can be shared across appropriate industries, domains and applications. To facilitate this, ontologies support a well-defined attribute inheritance model. OWL produces this more expressive semantics, and specifies that the semantics can provide "mechanisms for more complex relationships between entities, including: means of restricting the attributes of classes in terms of number and type, means of inferring that items with various attributes are members of a particular class, a well-defined inheritance model for attributes, and similar semantic extensions to basic semantics." Thus, broader knowledge (called upper-level ontologies) can be captured, which can then be further refined to support specific domains (domain ontologies).

Semantic understanding of data depends on a common vocabulary that defines terms and relationships. RDF Schema provides a vocabulary framework that supports typing and subtyping, and the ability to define data types. More detailed ontologies can be created using OWL, which relies on RDF Schema but provides additional semantic terms in its own namespace. OWL is defined by species or profile. Providing a configuration file that restricts the use of terms can make implementation simpler by including an inference engine that can be used. OWL Lite (for users primarily needing taxonomic hierarchies and simple constraint capabilities) is available for taxonomy and simple constraints; OWL DL (so named for its correspondence with Description Logics) is available for full expressiveness; and OWL Full is available for No constraints on expressiveness.

The SQL Protocol and RDF Query Language (SPARQL) is a SQL-like language for querying RDF, including RDF Schema or OWL. SPAROL is used to query RDF graph schemas and return results from selected subgraphs. SPARQL can be used to query ontologies as well as instantiate model data. SPARQL results can be rendered in traditional form for use in Excel, MS SQL Reporting Services, etc. SPARQOL is a tool for accessing highly distributed data to leverage traditional analytical tools.

ISO 15926 is an example of concrete implementation by OWL etc. in lifecycle data management in the oil and gas industry.

model server

This section explains the role of the model server as a runtime server for semantic models.

A model server (or model manager) provides a runtime framework for deploying models. A model server must support a number of key functional services to persist and manage models (ontologies) and model instance data. It must also provide tools and APIs for querying and updating model and instance data. Next, the role of the model server provides execution capabilities for the semantic models discussed above. This functionality is provided through open source projects such as Jena, Joseki, Sesame, and Pellet.

Model servers support many different persistence layers, including databases and files (usually in RDF/XML format, although N3 and Turtle are two other popular representations). Although relational databases can be used to support the persistence of RDF data, queries on RDF data (graph-based data) stored in relational databases (RDBs) are often inefficient and cannot be performed without changing the database schema. The ability to alter the data model may be lost. Ternary store is a special-purpose database designed for storing and querying RDF data. Its data structure is optimized for data stored in a triple structure, which corresponds to the subject-predicate-object form of RDF. Both Jena and Sesame provide ternary storage.

When we consider the model server at this level, there is no requirement to understand the structure of the persisted data. However, understanding the data becomes relevant when additional model server functionality is considered. Both Jena and Sesame provide great examples.

First of all, we should note that what Jena provides is "a Java framework for building semantic computing applications", rather than providing a complete model server. Specifically, Joseki is an open source subproject of Jena that provides server capabilities that provide an HTTP interface for RDF data, and an interface for SPARQL queries and updates. In addition, Jena provides a programming interface for RDF data and an inference engine. With this additional capability, Jena does need to "understand" RDF ontologies. Inference or inference means being able to deduce facts that are not directly expressed by an ontology.

Jena provides an inference engine to support reasoning in RDF, RDFS, and OWL, but it is incomplete in some cases. Jena provides a pluggable interface so that additional inference engines can be integrated. For example, Pellet is an open source Java reasoner that fully supports OWL DL and plugs into Jena. With this type of extensibility, Jena supports languages ​​such as RDFS and OWL, and enables data inference from instance data and class descriptions.

Like Jena, Sesame provides a Java framework that supports persistence, interface APIs, and reasoning. However, reasoning in Sesame supports RDF and RDFS, but not OWL. For a set of RDF or RDFS data, Sesame can be queried and hidden information found. Since anything that can be inferred can also be asserted, one way to support inference is to explicitly add implicit information to the repository when the data is initially created. This is the Sesame method.

Semantic Model and Model Management Middleware

This section describes the semantic model services provided through the model management middleware.

The purpose of model management middleware is to provide a framework that simplifies the creation of applications centered on real-world semantic models and enables the integration of real-time operational data and related enterprise applications. A key component of the model management middleware framework is the basic set of services for deploying, running, and managing semantic models based on the previously described model service types. Furthermore, the middleware framework should support a class of model ontologies and their instantiations. For example, an ontology can be based on industry standards (such as ISA-95, ISA-88, and ISO 15926) and support the definition of an enterprise model, including assets, each material transformation, and related measurements.

Another key component of the framework's architecture is support for model-aware adapters, allowing the integration of various types of endpoints (OPC, database and web service access applications such as CAD), and the mapping of information flowing between these endpoints and model elements.

Therefore, the middleware framework provides two views:

1. A reference model (ie, an ontology) defines the classes that exist in the model and the relationships between them, but does not correspond to any particular enterprise or asset.
2. The instantiated model defines instances of classes that directly reference real-world entities. They are populated with a set of properties (e.g. location, temperature) and relationships to other instantiated entities in the model.

As an example of how to model the real world using industry standards (ISA-88/95, OAGIS, MIMOSA, etc.), consider the following example, based on a paint manufacturer's project.

Classes in ISA-95: Enterprise, Site, Area, and Production Unit are instantiated. These are used with additional work equipment classes to define the physical model from the enterprise level down to the specific work equipment level.

At the worker device level, typically, measurement classes are attached and mapped to terminal data adapters and specific data sources.

Once a model is instantiated and mapped to an endpoint through the adapter layer, the model can now be used in a number of ways to achieve the business benefits described previously.

In the example paint manufacturing business, applications that need to obtain information about assets such as storage tanks now go to a single location (the model server hosting the instanced models) to access that information. This includes real-time information about the tank (for example, temperature), historical information (for example, the average temperature for the week), or more complex types of information (for example, open work orders for this tank or such tanks).

The model server provides:

• These applications use consistent interface methods for queries. (e.g., SPARQL) to obtain operational information about tanks, regardless of the true source of the information, such as a SCADA system, an operational database, or an application such as SAP or Maximo.
• The tank representation is consistent with the enterprise hierarchy surrounding the tank and is based on industry standards (ISA-95, etc.). The canonical form is maintained regardless of the underlying format used in the end system.
• Tank information is now easily extensible to introduce new information deemed useful in the future. For example, a new requirement related to equipment failure in an external asset management system is easily linked to equipment in the model so that failure information can be queried through the same model context. The model also provides a real-world context-based "canvas" to simplify configuration of aspects of production control, such as calculating key performance indicators (KPIs), defining actions required for operational events, and generating alerts for detected problems. Now, the type of information can be associated with an object in the model and then easily made context sensitive in the model.
• Likewise, relationships in the semantic model now make it easier for applications to look laterally at this information in the model to answer questions that were not anticipated when the model was originally created. For example, a paint company contains similar types of motors from different suppliers that can provide the same function. With relationships in the model, such as "motor type A <equivalent> to motor type B", a report can easily be generated showing the performance characteristics of all motors of a similar type currently in use in production (across regions, if desired), so future Better supplier decisions will be made. In doing so, the analysis concluded that maintenance action was required to replace one type of motor because the other type performed much better. Note that in this example, the relationship showing equivalence does not have to be present in the model as originally implemented and deployed. These can be added later based on new knowledge.

To sum up, the extension framework of application integration capability based on semantic model includes:

• Manipulate Entity Models: Manipulate entity models (e.g., tanks, pumps) and their relationships to support data queries that may be involved in many different systems in a real-world context. This is a powerful concept that allows us to build intelligence between entities (and underlying systems) to support analytics and optimization for failure prediction, abnormal behavior detection, and product quality problem detection and prevention.
• Establish a global namespace: establish common naming definitions and information access methods for applications to refer to entities, such as assets, that may be named and identified differently by multiple enterprise subsystems, to protect applications from knowledge of these subsystems details of your system (for example, SCADA/DCS systems, OPC servers, SAP or Maximo).
• Define canonical forms: Define canonical forms to reference information associated with operating entities in the enterprise. For example, the temperature of a tank used to mix paint can be obtained from a lower-level OPC server, or a work order can be obtained from SAP or Maximo. As mentioned earlier, industry standards can be used to provide definitions for this specification form, with the advantage of being able to build on accepted definitions and vocabularies for common entities such as devices, locations, and people.
• Provides an enterprise application programming interface: provides a global interface for applications to query and update operational entities and their associated data, so that applications do not need to know which subsystem owns any given entity or associated data (for example, OPC server, SAP, or Maximo wait). The application provides a complete view of enterprise data based on a real-world model corresponding to the data. This makes it easier to add new underlying systems, since their details are hidden behind the model.
• Provides a means of coordinating changes across all SORs and verifying configuration consistency across all SORs by associating configurations to approved configuration sets.
• Calculates the current risk level in the facility based on the current values ​​defined by HAZOP.

Example: Manufacturing Operations and Business Intelligence in Layer 3 Workflow Mapped to Layer 4

The operational processes that exist in a manufacturing enterprise clearly define domain-specific ontologies.

For example, an asset management SOP that is changing the status of an asset links together asset data, reason for change, and many other pieces of information. The information it operates on is well understood by the operator using this SOP. Analysis of process definitions quickly generates entities and relationships as defined above, but in a localized, domain-specific semantic context. The process not only interacts with multiple systems, but also has a defined timeline and sequence of events and activity calls. Each touchpoint generates an entry for our information lineage, while the workflow itself defines the ontology of the domain it operates in.

When analyzing semantic modeling and lineage, processes already existing in a manufacturing enterprise provide a rich source of metadata needed to define domain-specific semantic models. Self-extending semantic information models can be applied by capturing these models in computer-executable form and connecting to SORs as needed. Each new process definition extends the model with new definitions and relationships.

An important side effect of this approach is that data from a single SOR is contextualized by each workflow that uses them. Often, different ontologies are added to the same data from the system depending on usage during operation. Likewise, if each workflow intelligently captures the transient data of its execution, rich lineage information is created.

By combining these two sources of metadata, with hierarchical query capabilities on the underlying systems, a powerful source of manufacturing BI and OI is created. Metadata from process definitions describe entities and relationships and can be presented to users in such a way as to assist them in query building activities with implicit context from business and operational processes.

put everything together

The following example is based on a batch management system built on a model platform, and utilizes multiple modeling techniques to enable people with different expertise and needs to easily add and adjust functions. In this example, the model of the platform is a combination of two different modeling techniques:

• Data Modeling: Defining data that represents abstract, domain-specific concepts. In short: a defined vocabulary forms the basis of data modeling. Data modeling allows industry standards like ISA-95 to coexist with localized, business-specific concepts and even system- and application-specific definitions.
• Service Modeling: Define the services or activities that interact with SORs and people using the data in the data model. Service modeling provides strongly typed definitions used by service implementers integrating with various SORs.

All activities defined in the model translate directly into domain-specific artifacts used by graphical tools built by domain experts.

Once defined, models form the foundation of the system, providing the building blocks for developers who implement services, process designers who build workflows, and information modelers who create queries to extract relevant information about the performance of manufacturing operations.

Model definitions are presented to process designers as high-level, domain-specific artifacts. Provides the benefit of implicit context definitions, forming the basis of the platform's semantic model for accessing operational information.

As new processes are defined and deployed into the system, the information model is updated to include the context implicit in the process definition and integrated with the concepts of the system's core information model.

Figure 2-5 represents a simple SOP that is run each time a batch of laboratory samples is drawn. This SOP is triggered by a schedule (every hour after setpoint 1 is reached) or by an event at the device when setpoint 2 is reached. After this process, the system finds the current equipment used by the batch from the batch management system. It then loads the specifications from the product lifecycle management (PLM) system to be used as instructions for the next step, which is performed by the operator.

Figure 2-5: Laboratory sample collection SOP

The next step is to issue a work order to the operator with information from the lot and PLM for actual sampling. Since this step is performed by humans, it can take a long time, but eventually the operator will indicate that the sample is ready and delivered to the laboratory. In the next step, the system issues a work order to the lab technician to check and verify that the sample has been received. The final step is to record the sample in the Laboratory Information Management System (LIMS), receiving the sample ID assigned to the sample by the LIMS. In a continuum of these steps, the process interfaces with the following:

• batch management system
• ERP/PLM
• MIS
• PLC
• people

This simple process captures many elements of the ontology and very important lineage of information. Figure 2-6 shows some of the concepts and relationships that can be extracted from this process. No matter where the data comes from, you can immediately build queries for the system, such as:

• What equipment is used to produce a batch?
• Who took the sample?
• How are samples collected?
• What size is used for this batch?

Figure 2-6: Laboratory sample collection SOP body

Now let's look at the resulting information. Every time a process runs, the execution of each step and all information about incoming and outgoing activities is recorded, including transient information that does not exist in SORs. For example, based on data from the PLM, "sampling procedure" instructions are generated and presented to the operator. It is not stored in any system of record associated with the process. PLM data may change over time, hampering our ability to know exactly what is being delivered to operators. Armed with this data, users can ask the system the following questions:

• When is the sampling time?
• When did the operator actually take the sample?
• What sampling procedures were used in the last month of operations?
• How long does it take on average for operators to respond to sample requests?

This example demonstrates how traditional SOA modeling can be combined with semantic models inferred from executable business processes to unlock and contextualize unique information not normally available from a single system of record. The use of information models simplifies end-user interaction with the system and creates data sources for BI tools.

in conclusion

The value of semantic models and semantic computation as key components of an integrated framework in building solutions is explained. This architecture is discussed in the context of some widely used well-known solution architectures centered around data, messaging, and services. Semantic models are described in general and then illustrated with a detailed example to show how a semantic model-based integration framework can serve as the basis for building solutions that drive business insight and efficiency.

Semantic models play a key role in the next evolution of solution architectures that support the business goal of gaining a more complete view of what is happening in operations and deriving business insights from that view. Semantic models and semantic computing applications based on industry standards such as ISO 15926 and ISA-95 and all their associated standards take it a step further, especially as application vendors adopt these standards.