Define the operating system architecture

introduce

Information systems provided by vendors are constantly evolving with new capabilities and implementation strategies. The complexity and variety of available options makes it difficult for many companies to adequately discuss and compare alternatives that may or may not meet their requirements.

Vendors typically promote an architecture supported by products or solutions in a company's or individual's toolbox. If a company doesn't have a clear vision for the architecture of its operating systems, it often takes a vendor approach. This approach may be the most appropriate for the system being developed; however, in many cases this is not the case.

In the absence of a target "future" architecture, adopting a vendor's approach is inevitable. With the increasing reliance on system agility and related operational management capabilities, the need to raise the bar is evident. Companies must be able to understand their production processes and structures as a basis for actual process improvement. Once understood, the status quo and target future architecture serve as a common basis for discussing and mapping alternatives.

This article presents, with examples, techniques for describing operating systems and engaging stakeholders in projects based on product-independent architectures.

This approach is a game-changer in negotiating with vendors, moving from a product-centric assessment to one where operating system capabilities are the focus of the discussion. The product selection process includes requirements and alignment with key design principles.

Introduces a range of state-of-the-art enterprise and solution architecture concepts that can be used as a starting point for developing an operating system architecture (OSA). This architecture can then be used to guide any project, from the smallest upgrade to the largest enterprise solution.

What is Operational Systems Architecture (OSA)?

Wikipedia describes system architecture this way: "A system structure or system architecture is the conceptual design that defines the structure and/or behavior of a system," while business operations are "those ongoing, repetitive (cyclic) activities that involve running a system. For A business in which stakeholders create value. The outcome of business operations is the capture of value from assets owned by the business. Assets can be tangible or intangible.”

Note: Operational activities are often referred to as "shop floor" or "front line" activities. For the purpose of this article, Manufacturing Operations Management (MOM) as described in ISA-95 is referred to simply as "operations" or "operations management" because many process industries refer to MOM simply as operations or industrial operations.

Operational systems represent those systems that support business and operational processes and activities. Operating system architecture refers to the conceptual design that defines the structure and/or behavior of an operating system. It describes a framework for how to apply operational technology (OT) to meet business objectives.

OSA is suitable for a wide range of organizations such as manufacturing, retail, consulting, mining, distribution and airlines. When OSA is applied within a manufacturing company, it is often referred to as a Manufacturing System Architecture (MSA). However, these concepts are not limited to any particular field. Most businesses have operational components, such as mining, energy, and even supply chains, that can be considered productive capabilities. OSA concepts apply equally to all of these areas.

The OSA definition of an operating system is influenced by many factors, including challenges in the environment (technology, culture, corporate structure, location, etc.) and business goals (agility, product mix, supply chain, etc.). Architectures can be represented by different artifacts (documents, principles, pictures, diagrams, requirements, specifications and standards, etc.) to suit the context.

In practice, these representations are often disconnected due to physical, cultural and business boundaries. The architectural representation of the operational sites in the group often varies based on history (upgrade plans, ownership, etc.) and the relationship between each plant and the engineering, information technology, and operations teams within the plant.

These aspects present many challenges for increasing operational efficiency and agility. Without a common point of reference and language, it is difficult to leverage best practices across organizational divisions in the plant or to discuss them across divisions within the company. Developing a generic OSA using standard tools and technical references is an important foundation for addressing these challenges. Considering the best practices of other practitioners can minimize the situation of "reinventing the wheel". With industry and technical standards, others (eg, suppliers and integrators) may be exposed to these standards during previous extinctions, enabling the concept of record to be recognized by others (eg, suppliers and integrators).

OSA's Relationship to Enterprise Architecture

Many companies interpret enterprise architecture as the definition and framework for applying architecture in practice. Enterprise architecture is traditionally applied in the field of information technology and is an important reference when introducing OSA into discussions.

The definition used in this document comes from the Massachusetts Institute of Technology (MIT) Center for Information Systems Research (MIT CISR), which defines enterprise architecture as "the organizational logic of business processes and IT infrastructure that reflects the integration and standardization of a company's operating model Require."

The Open Group Architecture Framework (TOGAF), created by The Open Foundation (www.opengroup.org/togaf), is a popular framework used by IT groups to define capabilities, development methodologies, content, and tools for defining and applying enterprise architecture . In TOGAF, a company defines one or more businesses. In TOGAF terminology, operations are considered enterprises, and OSA defines the enterprise architecture for operating enterprises.

From an enterprise architecture perspective, OSA is considered the application of enterprise architecture (EA) concepts to the operational components of a company. From an OSA perspective, compared to TOGAF, OSA provides an operations-focused framework and leverages other tools (for example, the Gartner Brick model) and specifications. It extends and refines the EA to meet operational needs.

Realize OSA

Challenges in developing an OSA include:

• Determining the scope of the OSA
• develop a sustainable architecture
• Develop a structure that the target audience can understand
• Develop a scalable architecture

Determining the scope of the OSA

The scope of the system has a significant impact on OSA. In the absence of clearly defined boundaries, OSA ends up describing a system with a wider scope than necessary. Scope creep is a well-known challenge of operating projects; scope creep does not affect OSA if the change is within the scope considered during OSA definition. However, if the OSA's development boundaries allow scope creep, the OSA will be more complex than necessary. Clearly defining scope and trusting actors to minimize scope creep facilitates the development of an OSA that is as detailed as the solution design.

A high-level overall architecture may be required, but only a portion of the architecture needs to be detailed at any point in time. It is important to limit the scope to the minimum capabilities required to support immediate needs. Limit the scope of the OSA to the minimum necessary to deliver business value, and continue to critically evaluate whether the scope can be simplified or further reduced. Redundant and non-value-adding activities are classic signs that need to be cut.

develop a sustainable architecture

This challenge often conflicts with the scope challenge. Does the scope allow for future expansion? This scope challenge can be minimized by developing the architecture as a roadmap and pushing non-essential activities to future spaces.

Apply the PASS principle: plan everything, start small.

Not all longevity concerns are against scope. In many cases, the principles that define OSA in terms of system components, system boundaries, and interoperability standards help narrow the scope and provide more robust solutions.

IT technology is reshaping the foundations of its architectural paradigms in a short period of time compared to many hardware and operational equipment time frames. This is an important factor in developing a persistent architecture. Operational hardware and equipment typically have a longer life cycle than IT technology, which affects the timeframe of the OSA roadmap. They can vary from three to fifteen years of many starts, stops and marginal successes (for companies with a MOM vision).

These timeframe aspects reinforce the need for OSA implementation (product, hardware, etc.) independence. The OSA must describe the basic elements of the system and which business requirements they support. The implementation of elements may vary across the company and change over time. These time-related implementation factors (current and future) are captured in OSA as a roadmap for each element. The Gartner Brick model describes the technical building blocks of the system (Bricks, Gartner | Delivering Actionable, Objective Insight to Executives and Their Teams ) and a roadmap for each brick. Gartner's building blocks and patterns provide a useful basis for capturing this information.

Develop a schema that your target audience can understand.

It is important to pre-vet your target audience by considering which formats and languages ​​are understandable. There are fundamental differences in how information, electrical, mechanical and quality engineers and finance personnel represent and interpret designs, in addition to the influence of prior personal experience. Multiple views are required to enable key stakeholders to understand and agree on the architecture. If a stakeholder cannot understand an OSA, he or she cannot be expected to sign it.

Develop a scalable architecture

Scalability itself has multiple meanings.

• Technical scalability: Scalable across hardware platforms, database technologies, operating systems, etc. OSA addresses this issue in technical area representations and requirements.
• Deployment Scalability: Scalable to various implementation sizes and performance needs. When developing OSA, the deployment scalability of the system was seen as a challenge from small to large operational projects to the largest enterprise solution projects. This deployment scalability can be expressed in OSA through principles and non-functional requirements.

OSA needs to be able to address these challenges within a coherent framework. OSA allows for the separation of the core definition of the architecture from the implementation aspects of the architecture. In practice, OSA implementations typically come in two forms:

• Enterprise Architecture (EA): EA identifies "patterns and practices" that are applied by the architecture of solutions implemented in an organization, with long-term stability and scalability. EA defines principles and concepts, logic and process design components in a format agreed upon by all stakeholders, reused across projects, and adjusted over time in sync with changing strategic directions and changing circumstances.
• Solution Architecture (SA): An SA typically represents the architecture of one or more specific projects that have (or have) target business goals. SA provides an overall technical solution for a specific increment (a program set that achieves a specific level of capability) and ties together the overall approach. SA typically encompasses all aspects of conceptual, logical, process, and physical design. The goal is to provide sufficient technical and implementation details to proceed with the development, testing, and implementation of one or more projects. Implementations often have "we needed it yesterday" time pressure and "tell us what we need to do" issues. Therefore, SA is more requirements-oriented in the operational context than in the business process domain.

In small projects and companies, it can be difficult to distinguish between EA and SA. In larger and more modular projects, the distinction (often necessary) is more clearly presented and evidenced by reuse of components and modularization of the system.

Derivation of OSA

There are many ways to develop an OSA for an organization or company. The two methods are:

1. Adopt existing products as the basis for OSA
2. Implementation of OSA representation independent of existing products

The first option may be a faster path, but has the side effect of not necessarily providing the proper architecture to meet the company's needs and connect the company to products/suppliers.

The second option requires more analysis and clarification of scope and methodology, which actually reduces effort in larger, more complex projects.

Use existing products as the basis for OSA

In the absence of an existing operating system model, companies often leverage data, integration, and process models defined in products used in operations and/or across the enterprise. This approach provides a solid foundation for many organizations. However, it has an implicit assumption that existing products have a conceptual design with sufficient attention to the needs of the operating system. Given that most products focus on specific aspects of an operating system and make specific assumptions in their development, this approach is unlikely to provide the basis for a broad-based operating system architecture.

A common direct consequence of this approach is that companies end up describing the architecture in terms of the product itself. They have pushed key analysis to the vendor. One sign is that there is no consensus on the production process beyond some basic representation based on physical equipment and bill of materials. If you ask about plant or process design, even in advanced terms, you'll see the product's screen or help system. That's not a bad thing in itself. However, the scope and definition of the product-dependent system is that it assumes that the supplier's product direction is the same as the company's direction.

Another consequence of this approach is that the product may not perform to its full capabilities. This is more likely in more complex products, such as ERP and MES/MOM systems. Implementation is understood from the point of view of the initial implementation, but since then people have moved on and no one really has a clear picture of what can be achieved and what has been achieved. This problem can also exist in product-agnostic approaches if care is not taken to preserve the intent of the application over time. However, this is more likely to happen in a vendor delivery model that typically does not focus on the scope of paid participation and uses a product development team from another department or another country in the system that is not managed by the implementation team Or access, in the integrator delivery model, the project team is focused on the integration team.

Implementation of a product-independent OSA representation

To achieve a product-independent OSA representation, the system is first defined in a form that focuses on the company's challenges and opportunities. Limited supplier involvement is included at this stage (for information only, not guidance); after the OSA has been defined to a satisfactory level of detail, suppliers are formally brought into the process. Companies that emphasize resources or skills often hire independent experts to facilitate the process.

OSA describes the structure and behavior of the system in an implementation-independent manner, with the level of detail determined by the company's needs. The OSA is related to the business drivers for the system, usually in the form of a capability roadmap for the system, aligned with the business capabilities and goals. It doesn't make sense to equip a teenager with a Ferrari for his first car. As the teenager matures, if his/her technical abilities and needs are still suitable for a sports car, then Ferrari may be the right choice.

The level of detail of the architecture varies with the breadth of the model, aligned with the needs of the company. For example, the company believes that more attention needs to be paid to production management and process control than to supply chain integration. Therefore, production management and process control are more detailed than other fields.

The advantage of this approach is that the scope and approach of the architecture aligns with the direction of the organization, supporting initiatives that span multiple products to implement requirements and multiple phases to achieve the intended functionality. Again, staging aligns with the maturity of the company and drives organizational flexibility in terms of processes and toolsets.

Typically, detailed knowledge of the system's architecture and requirements is transferred from the end user to the vendor as the end user adopts the product or the vendor's architecture. In some cases, this is a reasonable trade-off. In other cases, it is a limiting factor, preventing users, organizations from unlocking the full capability of operational capabilities (which can be measured in many ways: ROI, throughput, etc.). Given that many vendors are global organizations, architects that vendors hire on projects may not be familiar with (and may not have the time to fully understand) the details of end-user systems. This situation is dangerous for end users.

Companies have developed effective solutions using both approaches. However, those companies that choose to implement a product-independent representation may have a more flexible, durable architecture that evolves over time and is able to work more effectively with suppliers to get what they need.

Some companies follow a product-based implementation approach because they are not sure how to approach the solution in a product/vendor independent form. Vendors trust their architecture to meet all needs in all environments and deliver the message through compelling presentations. To take a product/vendor independent direction, end users need to be confident in their ability to adopt this approach. To meet this need, companies often hire analysts and SMEs experts (SMEs).

Steps to develop a product-independent OSA

1. Form OSA team structure

As with any activity, to be successful, the formation of an OSA must be fueled by corporate support and budget. Disruptive impacts to operations can be reduced by starting with pilot projects and learning from these experiences. Companies that see the value in this approach form teams of architects from different disciplines, with a steering committee providing guidance to each team. In projects of all sizes, the ability to bring in external SMEs and work with external consultancies is part of the process. Whether the commitment is to one architect or multiple architects, business involvement and support are key elements of the process.

This process is best engaged by a multidisciplinary team that includes stakeholders from all disciplines and technical areas of the company. The composition of the operations/business area team may include one or more members from the following disciplines:

• Engineering / Process Engineering
• Financial Director and Planner
• Operations/Continuous Improvement
• Quality Assurance/Compliance
• technology
• information Technology
• maintain
• marketing
• supply chain
• Production
• subject matter expert
• information architecture
• Automation/Control
• MOM/MES
• ERP
• Project Management / Facilitation

2. Development-OSA

The evolution of a product-independent OSA is relatively straightforward, following some basic steps shown in Figure 4-1. The process is iterative, starting at the macro level and drilling down to areas of greatest value to the business drivers. 

Figure 4-1: OSA Aligned development steps

When drilling down into these steps using business drivers, a basic process is used, similar to that used in operational systems engineering and development:

1. Identify and prioritize existing business needs and operational challenges and pain points.
2. Identify gaps to best-in-class companies, technologies, and known standards.
3. Rank the value of the business based on existing business needs and operational pain points.

The ranking decisions for these user needs depend on efficient operational workflows and are technology-agnostic.

A compelling operational systems architecture aligns with and supports operational activities that address business needs and drivers. As part of developing OSA user requirements and priorities, extensive interviews and reviews of current business roadmaps and priorities are required.

1. Business Roadmap Review

• What is the current state of the environment?
• What is the future environment?
• What are the long-term goals?
• What are the steps to get there? according to:
  • business maturity
  • People and Process
• Where are the key added value and cultural sensitivities in the roadmap?

1. Discovery of system functionality/architecture

• What capabilities are required to enable steps in a business process?
• Determine the underlying architecture:
  • What are some advanced concepts?
  • What kind of architecture can support the business roadmap?
  • The architecture must account for the end state and demonstrate its evolution relative to the end state.
• Consider operational and IT capabilities in terms of existing systems and technology adoption:
  • Business maturity, the ability to understand and leverage concepts requires cultural and training exercises.
  • Capabilities appropriate to the business maturity level. There is usually a lightweight interim solution that fits the immediate maturity level of the business. As maturity grows, more capable systems must be planned.
• Which technical capabilities are at a high level?

1. Classification against MOM and IT standards

• Representation of system components according to standards (ISA, ISO, IEC, etc.)
• Compare system architectures relative to existing technologies (WS, SOA, REST, etc.).
• Classify the capability/maturity of the system relative to other systems (best in class, etc.) to identify gaps/opportunities.

1. Capability/architecture roadmap development

• Determine the end state of the technology/capability.
• Document the steps towards the end state in terms of capabilities and architecture.

1. Rank the steps required by the business

• Align capabilities and architecture roadmaps with business needs.

1. Refine/drill down on high-value areas

The result is a prioritized list of operational capabilities of the system, which must then be aligned with business value and supported by a business case for development/implementation. This is an important aspect of OSA development. There is no point in designing an elegant architecture for a utopian vision if it has nothing to do with the needs and values ​​of the business.

Another way of stating the intent of an OSA is that an effective OSA enables people and systems to meet business needs. The operating system (human and machine) can more effectively meet business needs (agility, efficiency, flexibility, etc.). OSA supports business processes and the continuous improvement of those processes.

What is an OSA like?

The representation and content of an operating system architecture depends on the environment it represents. The components of a typical OSA can be described as templates for a specific representation.

Typical OSA components are (these components are described in High Level Architecture):

1. Align business drivers with OSA roadmap and MOM URS
2. Guiding Principles
3. Standards Support and Conformance
4. MOM System Architecture (true core of OSA)

Published standards and frameworks for the requirements and representation of system and enterprise architecture are:

• Zachman Framework ( http://en.wikipedia.org/wiki/Zachman_Framework )
• TOGA 9
• ISO/IEC 40202, ISO 15926, etc.
• Gartner Brick Model
• ISA-88、ISA-95、ISA-99、ISA-100、ISA-101、ISA-104、ISA-106 etc.

The adoption and degree of compliance with any of these standards will depend on the environment, culture and processes of the organization. This architecture document does not delve into any of these standards, but it is recommended for review as a reference architecture. The level adopted by the actual standard must be based on added value to OSA. This is an important consideration.

1. Align business drivers with OSA Roadmap and MOM URS

Business drivers and roadmaps are often expressed in other documents referenced by the OSA; typically, these documents are owned by stakeholders from their respective domains (operations, engineering, IT, etc.). The scope of the Business Drivers may cover areas of little value to OSA, but include a set of goals and milestones that provide OSA with valuable context and direction. Business drivers and roadmaps suggest which specific issues are important, and why. OSA provides a framework to achieve these goals. A summary of the key business drivers and vision in the OSA, provided in the OSA or as a separate document, to provide background information on what the target architecture supports and why.

current state definition

Where is the current production and operation management system?

What are the challenges and opportunities facing today?

The future or end state must be effectively defined in an operations management User Requirements Specification (URS), which must first fully define the current state of operations management and supporting systems and processes. Functional and cultural gaps in the OSA roadmap must be characterized for planning and ROI calculations.

final state definition

The end state definition answers the question: where does the future production system need to be?

A typical operational systems optimization roadmap covers three to fifteen years, depending on the level of culture change management required.

For those who are new to facilities or interacting with production systems in the future, what will stand out?

In five or ten years, what kind of operation form is required to become globally competitive? You must know that it will take three to fifteen years to achieve this goal?

The steps required to transition from the current state to the final state

Stakeholders always want to see the incremental small steps they fund provide ROI benefits while ensuring that those steps are also aligned with the broader vision. What is the ROI for each incremental step required to transition from the current state to the final state?

These steps must be small enough to allow the project/work plan to be established and monitored by project management, while at the same time not exceeding six to nine months if possible. This approach preserves the flexibility to adapt to changing needs and circumstances as the project progresses. It may also take some iterations to get the final result.

Fine-grained details in the first step: MOM URS

While operations management URS documentation is strategic, many stakeholders think tactically. Stakeholders always view the URS as a first step and value it because it is the first "litmus test" for the proposed architecture. However, the URS must provide and communicate the framework and methodology for functional and OSA design and deployment to stakeholders so that they have a clear understanding of the resources and costs required for design and deployment.

A description of the business drivers and the OSA roadmap. Most likely to follow the source document. However, some generalizations are made to the noun structures presented below. Its format can be similar to the introduction of a vision document, describing the current state, the future state, and how to get there in small, achievable steps

The architecture described in the OSA document provides the underlying capabilities to implement the project or program elements described in this section.

2. Guiding principles

OSA is guided by key principles against which to structure, guide, and align OSA with business and operational requirements. Typical OSA principles are described below, some of which are considered system-level requirements. In fact, many of the guidelines translate into requirements for suppliers.

In many cases, it is acceptable to have a single list of guiding principles, since that list is often covered by descriptions of limited scope (program data integrity improvements, project line speed optimization, etc.). In other cases, the scope of the OSA is broad and the guiding principles exist in separate documents, grouped by chapters.

The following list of guidelines represents a sample of what a guideline might contain. It is not prescriptive, but rather indicative of the subjects and elements to be represented.

• system representation
  • The architecture complies with the ISA-95 standard.
  • The architecture complies with the ISA-88 standard.
  • Business processes are expressed using the BPMN standard.
  • Diagrams are rendered using UML 2.2 structures.
  • Functional descriptions are vendor-independent.
  • Implementations running in a virtual environment have well-defined scalability with performance and availability requirements, and describe which features available in the virtual environment will be utilized.
• Diagnostics/Health
  • System outages are reported every five minutes or more.
  • Safety
  • All applications integrated into the system are assessed for data security, including:
    • All data transmitted over the network must be encrypted.
    • No data shall be stored unencrypted.
    • Usernames and passwords should be managed in a secure environment.
    • compliance
  • System data archiving requirements to retain operational, material, product and financial data for a period of time.
• reliability
  • System recovery in case of disaster recovery (DR) is performed within 24 hours.

Note: This is an example; going from DR to a vertical usually requires a tighter timeline.

• Role
  • Applications (MES/MOM, PLM, ERP, etc.) focus on business rules.
  • Message mediation applications (EAI and BPM products, etc.) focus on message mediation (transmission, distribution, and delivery rules).
• interface/message
  • Messages are defined in industry standards (B2MML, EDIFACT, etc.) and are therefore application-independent.
  • Mediation engines are application-agnostic rules that focus on transport, delivery, and mapping functions.
  • Messaging from the application-level interface to the standard model is performed in the standard mapping component.
  • The API parameters of the API are treated as message definitions and are as application-neutral as possible; any application-specific parameters are mapped into the standard model via an intermediary mapping component.
  • Message flow follows a predefined pattern.
  • The code components and configuration for the dialog are managed in a versioned repository.
  • Information exchange is documented in standard procedures
  • Applications are loosely coupled. Message exchanges must be asynchronous. Synchronous message exchanges are implemented as coordinated asynchronous conversations.
• solution development
  • 80% of message implementation is through configuration; 20% require custom implementation once the factory model and manufacturing information model are defined.
  • Where custom implementations are deployed, code and components are managed in version-controlled repositories.

3. Standards Support and Conformance

Indicating which standards are supported and applied is a valuable basis for setting the context for architectural presentations. It's a good idea to provide a reference to the appropriate standard so readers can look up the standard if needed.

In some requirements documents, it is appropriate to add an appendix indicating the relevant components of the standard that are being used with the architecture. For example, ISA-88/95 equipment role model elements might be documented in an appendix when representing an operational facility using ISA-88/95.

The level of compliance (or non-compliance) with a given standard should also be documented. Standards are rarely adopted or fully adhered to. In operational implementations, standards are often used as a common reference point (eg, ISA-88, ISA-95). In such cases, the standard may not meet all of the organization's needs, but serves as a valuable reference point through which any deviations can be clearly expressed. Compliance with standards is not always desirable. It is often a valuable tool when understanding consistency and variance during supplier evaluation, especially when multiple suppliers are involved or bidding.

This approach helps participating suppliers who are familiar with the standard understand the language used to describe the system and understand where the standard does not apply.

4. MOM system architecture

Schema representations are the basis of OSA. It defines the basis of the operating system with which it is related. OSA is a reference architecture for operating systems, in a manner similar to how enterprise architects define reference enterprise architectures for enterprise systems.

A typical MOM system architecture represents three basic components as follows:

1. MOM High Level Architecture (MOM HLA)
2. architecture model
3. information flow pattern

These three components are described in more detail in The Zachman Framework ( http://en.wikipedia.org/wiki/Zachman_Framework ).

The Zachman Framework is an enterprise architecture framework that provides a formal, highly structured way to view and define an enterprise. As shown in Figure 4-2, the Zachman framework consists of a two-dimensional classification matrix based on the intersection of six communication questions (Why, How, What, Who, Where, When).

The Zachman Framework is not a methodology because it does not imply any specific methodology or process for collecting, managing, or using the information it describes. The framework is named for its creator, John Zachman, who first developed the concept at IBM in the 1980s. It has been updated several times since.

A Zachman "framework" is a pattern for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account who the artifacts are intended for (e.g., business owners and builders) and are solving specific problems ( For example, data and functions).

Figure 4-2: Zachman Enterprise Architecture Framework

4.1. MOM High Level Architecture (MOM HLA)

OSA was introduced as the MOM High Level Architecture (MOM HLA) to identify the key elements of the architecture covered within the scope of the architecture. In larger systems ("big" is not limited to size; it can also describe complexity, variation, etc.), the architecture is decomposed into key views of the system that are particularly relevant to specific stakeholders.

The MOM HLA typically contains a combination of key concepts and views of the system that set the intent, focus, and scope of the architecture. Possibly also depicts the device/hardware level that helps convey the architecture. The brick model can also be used for MOM HLA representation.

4.2. Architecture Model

Models describe the components of the architecture and the interactions between them. There are many modeling tools available for describing systems. This section details some of the tools applied to manufacturing operations systems.

ArchiMate ( http://www.opengroup.org/subjectareas/enterprise/archimate ) is an Open Group Standard, an open and independent enterprise architecture modeling language supported by various tool vendors and consulting firms. ArchiMate provides tools that enable enterprise architects to describe, analyze and visualize relationships between business domains in an unambiguous manner. Archimate 2 has been developed to be fully consistent with TOGAF.

ArchiMate provides a wide range of views that combine to convey architecture in context.

4.2.1. Brick Model

The brick model shown is based on the Gartner brick pattern to help identify key areas in the Layer 4 business and Layer 3 MOM technology domains, as shown in Figure 4-3. These domains are built with bricks. Each of these building blocks can be expanded to present the technology roadmap within the building block.

Figure 4-3: Example of a MOM brick model

4.2.2. Logical Model

The logical model is the representation of the main components in the system and some key interfaces inside and outside the system. These manifestations vary by audience.

4.2.3. Standard model of manufacturing operation system

There are various models of manufacturing operations systems. IEC, ISO, NEMA, ISA, and MIMOSA are just a few examples of a broad set of standards that provide model templates, based on discussions by expert groups over the years. These models are used as reference templates for a given OSA implementation. The following sections illustrate some of the models derived from the ISA standard as they apply to operating systems.

4.2.3.1. Organization Model

The Organizational Model (OM) is a hierarchy of Organizational Units (OUs). The concept is widely used throughout business systems and operating systems such as Active Directory.

Elements used to represent enterprises and production systems are associated with this model. The organizational model is the backbone that divides the system into regions of specified scope and behavior. The ISA-95 and ISA-88 functional hierarchies and equipment role models form a useful basis for building architectural organizational models in a manufacturing operations environment. The hierarchical nature of these models enables the specification of an enterprise to be broken down to a level of detail from the enterprise, to the field, to the plant/shop work unit. This separation allows defining the scope of activities and production system elements.

Are the operating procedures of the machine, site or establishment within its scope of application?

The hierarchy allows insight into the specific needs of key domains and manages the relationships between domains in the overall system. Differences (and similarities) in processing semantics between batch processing, discrete, continuous, and mixed production areas can be examined in this area.

Example: Using the ISA-95 device role model construct shown in Figure 4-4, a template for line representation was developed. This template is applied to various plants to define a standard model of a manufacturing facility. This model is used to further decompose the manufacturing facility into a coherent representation. At first glance, the proposed simple approach is limited in its ability to allow for variations in device definitions between and within physical facilities. The representation of related models (resources, workflows, infrastructure, etc.) provides practitioners with the tools to comprehensively structure manufacturing operations in various physical operating environments. A similar approach can also be used to geographically define enterprise representations of plants across global or national organizations.

Figure 4-4: Example ISA-95 device role model

4.2.3.2. Resource Model

Resources are an important definition of operating system capabilities. A correct representation is critical to understanding how to improve the system in terms of throughput, flexibility, and quality. There are important relationships between resources in the system and executed workflows. Before defining a resource model, it is best practice to define workflow types, resources (equipment, materials, and people) and operational workflows:

• Work is physical or mental activity performed in order to achieve a purpose or result.
• Resources are the elements needed to get work done in a process or workflow.
• A workflow is a sequence of steps to perform work. A sequence can be a step, and each step can be decomposed into subordinate steps in a hierarchical model.

The resource model defines the representation of a resource as:

• person: personnel
• machine: production equipment
• material: material
• Method: Business, etc. (Workflow representation based on ISA-95)
• ring: environment

There is an interesting interaction here that needs to be clarified: people and equipment are working, but also in steps of the workflow, as inputs (requirements) to the workflow.

A person or device uses other resources to complete work in a system. The definition of resources in a system indicates the system's ability to perform work. The range of resources available for a given activity is defined by the organizational model. This is important for the definition of production scheduling and device arbitration in operating systems.

In some domains, processing devices (controllers, data centers, racks, etc.) are defined as resources. Resources are an important definition of operating system capabilities.

4.2.3.3. Workflow diagram

Accurately representing different levels of workflow and how they interact is important to capturing the nature of operational functions and how they change within a company.

There are several interpretations of workflow in operations, including:

• formula
• Routes: Main routes and production routings for discrete industries
• Process segments, operating segments, and work process segments as defined in ISA-95
• Business Process
• Instructions for Work (WI) or Standard Operating Procedures (SOP)
• Process: Recipe, Unit and Control Recipe as defined in ISA-88

There are many potential parallels in the above list:

• The semantics of these representations are basically the same, although the visualization and semantics of each ontology make them look quite different.
• It is important to capture every representation of a workflow in an operational system and present it for stakeholder agreement.
• Manufacturing operations have multiple levels of workflow and complexity depending on the level of detail required. The ability to accurately represent workflows at different levels and their interactions and dependencies is important to capture the required level of detailed operating system functionality, including workflow changes in company operations and factories.

MOM workflow example

The diagram in Figure 4-5 represents some different forms of workflow in an operating system, and the diagram is generic. In practice, the implementation of an operating system will be much simpler, since it represents a company-specific production and operating system and may use specific standards such as Business Process Modeling Notation (BPMN).

Figure 4-5 Represents interactive workflows in production and operations systems using BPMN notation

Notes on the example in Figure 4-5:

• Different workflow representations are linked together to perform "the entire production process.
• Enterprise-level processes are expanded in detail due to consideration of the physical environment of the production process.
• The left side Enterprise, Site, Work Center, and Work Unit organizational units derived from ISA-95 divide information into manageable sections.
• Workflows (mixing, making, packaging) can be implemented as recipes or routes, depending on the company.
• Circles represent steps in the workflow. Each has inputs and outputs defined as resources and parameters (see ISA-95 and ISA-88 examples).
• WI and SOP are workflows.
• The goal of the workflow is to produce the products defined in the order.
• Workflows for Mix, Make, and Pack are bound to resources in work centers and work units to produce products.
• WI/SOP/SOC is an important workflow at the core of the production process. In many cases, they, along with the control formulation, are where the rubber meets the road.

4.2.3.4. Standard symbols

Use standard symbols in OSA whenever possible. In the real world, there may be reasons to combine or expand symbols or use non-standard symbols to convey information. However, standard formulations should be used whenever possible, as practitioners in the organization are more likely to understand, appreciate and support them.

Commonly used symbols are:

• Business Process Modeling Notation
• Unified Modeling Language (UML)
• ISA-88 Part 3

While there are many specialized tools available, a lot can be done using templates provided by off-the-shelf desktop tools.

4.2.4 Infrastructure Model

Infrastructure elements are brought together in an infrastructure context, indicating the elements of interest to the system and the specification of those elements. The resulting infrastructure model demonstrates the underlying systems and communication networks required to support OSA application-level and workflow-level functionality.

The model provides an indication of key infrastructure elements, including:

• server
• frame
• cabinet
• engine room
• client
• network model

4.2.4.1. Server

Servers come in many forms. Combining server representations into a coherent representation is useful to consolidate workflow capabilities across enterprise, site, production line, and machine-level systems. The expansion of workflow capabilities in embedded systems has blurred the line between what is information and what is pure control in an operating system. Thus, the ability to perform advanced computations now is a question of what system level is best suited to deploy that capability in a reusable and scalable form.

The servers typically represented in the schema are:

• blade server: A physical or virtualized hypervisor environment that typically executes Windows- or Linux-based applications. Insert into server rack.
• Data Concentrator Modules: These industrial controller modules are focused on data collection, with logic for data storage and data forwarding or embedded historian modules.
• Line Controller Modules: Industrial controller modules target line level control.
• Machine Controllers: Industrial controller modules for individual machine/work cell control (e.g. mixers).
• Device Server Module: The server manages connections to devices within the plant/operational facility.

The choice of representative server will depend on the scope of the architecture.

4.2.4.2. Rack

Racks host servers on lines, sites, and data centers, providing power and communications to items connected to them. Although uncommon in operational architecture diagrams, they can be important characteristics when considering the assignment of functions to specific server/rack instances.

The represented rack types are:

• Server Rack: A host for server blades in a server room or data center.
• Controller Rack: Host of industrial controller modules in the form of:
  • Process Controllers - Machines: Machine-level basic control of individual machines or machines within a work cell
  • Process Controllers - Production Line: Line-level control of the production line
  • Data Concentrators: Data Acquisition and Download Gateways/Bridges for Automation/Information Networks

4.2.4.3. Cabinet

For completeness, the cabinet houses the process control rack. In control systems, these are called motor control cabinets or motor control units, while in server rooms they are simply called cabinets.

4.2.4.4. Computer room

These are enclosed areas in data centers, production sites or production lines that contain racks and cabinets. They are often referred to as computer rooms.

4.2.4.5. Client

Definition of user and functional requirements for all clients in the system including HMI, PC client and mobile device client.

4.2.5. Network Model

The model indicates the elements of interest to the system and the specification of those elements.

Here is a representation of the control and information network within the system:

• This representation means that networks are segregated by VLANs, bridges, routers, and firewalls.
• The network spans fixed line infrastructure (fibre/copper) and wireless connections.
• Shall also represent a network-capable machine on the network.
• Network configurations often span control, plant information, and enterprise networks, indicating a separation of networks.
• Access to the network by external suppliers and contractors is defined by communication gateways and configured firewalls.

The model also includes representations of network protocols such as:

• TCP/IP
• Ethernet IP
• device network
• Professional Network
• professional bus
• Modbus TCP

4.3. Information Flow (AKA Data Exchange)

Information flow (also known as data exchange) captures some of the dynamic interactions that occur within the system. They can be applied to all domains within the system. The level of detail rendered is system dependent. A series of information flow representations can be used to describe the exchange of information at the macro and micro levels.

The data exchange classifications for information flow representation and specification are:

• data collection
• database
• Master Data Definitions and Owners
• Report
• configuration
• implement
• Post-production

OSA has many architectural concepts available; some of them are:

• Enterprise Service Bus (ESB)
• Manufacturing Message Bus (MMB)
• Manufacturing Operations Service Bus (MSB)
• Operational Message Bus (OMB)
• Event Driven Architecture (EDA)
• Service Oriented Architecture (SOA)

Machine-to-machine (M2M) information exchange architectures under these architectures may affect or fit a specific set of information flows. Some available schemas are:

• Internet service
• publish/subscribe
• Representational State Transfer (REST)
• data replication

OSA selects these methods and aligns them with what is appropriate for the company's purposes.

Driving these machine-to-machine exchanges are a variety of technologies, the choice of which depends on the application:

• Replication Engine: An engine with simple database-to-database data exchange capabilities.
• Message processing engine: A message processing engine that extracts information from the source, performs basic mediation (transformation/mapping), and loads into the target system.
• Routing and mediation engine: A message processing engine that extends the transformation capabilities of the messaging engine to provide routing and more complex mediation capabilities.
• Process Orchestration: Applications extend the transformation capabilities of the messaging engine by adding the ability to perform complex message processing and logic on messages during the transformation phase.

Realize Manufacturing OSA

With the OSA completed, a canvas has been created to map the functional solution, requirements, and vendor's offerings. The canvas allows its creators to measure the fit of various vendor technologies against the OSA roadmap and identify the best fit and gaps that must be filled to achieve the desired level of functionality. In this environment, vendors (and others) are encouraged to introduce additional functionality and architectural patterns into their plans. The OSA roadmap itself evolves each year in a manufacturing transformation as end users mature and learn more.

As mentioned earlier, an alternative to this approach is to allow the vendor to manage requirements gathering and solution description. Doing this, intentionally or not, aligns the architecture and its evolution direction with its product direction, which may or may not be aligned with business needs. In such cases, it is advisable to have an independent, objective view of each supplier's activities to prevent supplier lock-in and missed opportunities.

Utilizing OSA is not a major change to the normal course of evolution of a company's operations. The following process illustrates how OSA is utilized in the development of new technologies:

• Concept – concept definition and value justification: Changes to operating systems are measured against a roadmap, which provides a clearer representation of changes to operating systems and the impact of those changes.
• Request for Information (RFI): Provide participants with documentation of the process utilizing the OSA and using industry standard terminology and structure to help structure discussions. The scope of changes is limited to the overall OSA high-level design in the roadmap. Any changes in range are appreciated. Additional information consistent with other aspects of the roadmap is identifiable and can be understood as appropriate to a wider scope.
• Request for Quotation/Tender (RFQ/RFT): Same concept as RFI, with special emphasis on scope definition. A clearer reference model provides a stronger basis for contract discussion and structuring.
• Project Implementation/Deployment: Less discussion of unclarified changes and issues early in the process through clearer scope definition.

Manage the development of OSA

The creation of a responsibility matrix helps stakeholder teams understand which areas they should be involved in. While this is primarily a project management function, having clearly defined roles and responsibilities is consistent with OSA's evolution. Stakeholders should know which areas they are contributing to and which areas they are signing off on.

summarize

Techniques and examples for developing OSA have been presented. While these architectures are often developed with external support, by leveraging the technology provided it is possible to create an effective vendor-independent OSA for the smallest projects all the way through to larger enterprise implementations.

With this capability, companies can better capture the true semantics of their operational processes without being affected by vendor bias. With these models, engagement with suppliers in implementation changes, with discussion of core concepts on the table before an order is placed, rather than being discovered during or after a project.