Connect981 – Content Dev

Glossary Tag: process monitoring

  • OEM portal

    An OEM portal is a secure online platform operated by an original equipment manufacturer (OEM) to provide controlled access to technical information, digital services, and collaboration tools for customers, maintenance organizations, and supply chain partners.

    What an OEM portal typically includes

    In industrial and aerospace environments, an OEM portal commonly provides:

    • Technical documentation such as manuals, service bulletins, drawings, and configuration data
    • Parts and service information including illustrated parts catalogs, approved parts lists, pricing, and lead times
    • Maintenance and MRO resources such as repair procedures, maintenance plans, and approved repair schemes
    • Configuration and serial data including build records, modification status, and applicable service bulletins for specific serials or tail numbers
    • Order and warranty services for placing parts orders, initiating returns, warranty claims, and tracking order status
    • Compliance-controlled documents such as certificates, regulatory notices, and export-controlled technical data under managed access
    • Integration endpoints like APIs, file exchanges, or web services that link ERP, MES, or MRO systems with OEM data

    How OEM portals are used in operations

    In regulated manufacturing and MRO environments, OEM portals are often used to:

    • Validate the latest approved configuration and repair instructions before performing work
    • Retrieve traceable documentation (for example, certificates, service bulletins, or engineering changes) tied to a serial number or tail number
    • Support parts planning and procurement by checking availability, supersessions, and alternates
    • Exchange maintenance and performance data back to the OEM when required by contract or program agreements
    • Provide evidence during audits and investigations that current OEM instructions and limits were used

    OEM portals and system integration

    OEM portals commonly interact with internal systems such as ERP, MES, PLM, and MRO software. Integration may include:

    • Pulling approved technical content from the portal into work instructions or digital travelers
    • Synchronizing parts master data, alternate parts, and effectivity
    • Linking service bulletin applicability to specific assets or configurations stored internally
    • Handling export-controlled or ITAR data under appropriate access controls and audit trails

    Poor integration can result in configuration mismatches, outdated instructions, or broken traceability across OEM, ERP, and MRO systems.

    Common confusion

    • OEM portal vs. supplier portal: An OEM portal is run by the original equipment manufacturer for its customers and partners. A supplier portal is typically run by a manufacturer or operator to manage its upstream suppliers.
    • OEM portal vs. MRO system: An OEM portal usually is not the system of record for work execution. It supplies reference data and services that are consumed by MRO or MES systems where work orders, labor, and inspections are recorded.

    Aerospace MRO context

    In aerospace MRO, OEM portals are widely used to access aircraft or engine manuals, service bulletins, engineering dispositions, and serialized configuration data. Maintenance organizations may need to demonstrate that they used the latest approved OEM content and that any portal-derived data was correctly mapped into their ERP, MRO, or MES environments while respecting export control and data handling requirements.

  • UTC

    UTC (Coordinated Universal Time) is the primary international time standard used to measure and synchronize time across different regions and systems. It does not observe local time zones or daylight saving rules. In industrial and manufacturing environments, UTC is commonly used for system clocks, event timestamps, and cross-site data integration so that time-based data from different plants can be compared and analyzed consistently.

    Key characteristics

    • Time standard, not a time zone: UTC is a reference time scale that remains constant worldwide. Local time zones are defined as offsets from UTC (for example, UTC+2 or UTC-5).
    • No daylight saving changes: UTC does not shift forward or backward seasonally, which avoids ambiguity and gaps in time-series data.
    • Basis for offsets: All civil time zones and many industrial scheduling and logging systems are defined using an offset from UTC.
    • System-level usage: Many OT, MES, historian, and ERP systems internally store timestamps in UTC, even if they display local time to users.

    Use in manufacturing and regulated environments

    In manufacturing operations, UTC is commonly used to:

    • Normalize event logs, alarms, batch records, and production data from multiple sites that operate in different time zones.
    • Support consistent calculation of time-based KPIs such as OEE, NPT, and on-time delivery across plants.
    • Improve traceability and auditability by providing unambiguous timestamps for quality records, electronic batch records, and equipment logs.
    • Align data integration between OT systems (for example, historians, PLC logs) and IT systems (for example, MES, ERP, LIMS) using a common time reference.

    Operational considerations

    Although systems may store data in UTC, operators usually work with local time for shifts, plant calendars, and work schedules. Practically, this often means:

    • System clocks are configured in UTC, with user interfaces converting to and from local time zones for display.
    • Shift definitions and plant calendars are defined in local time, while underlying timestamps remain in UTC for cross-site reporting.
    • Data warehouses and analytics platforms convert local timestamps to UTC to combine and compare data from different locations.

    Common confusion

    • UTC vs GMT: GMT (Greenwich Mean Time) is a historical time standard and sometimes used informally as a time zone. UTC is the modern, precise standard used in computing and industrial systems. For most operational uses in manufacturing, UTC is the relevant term.
    • UTC vs local time zone: UTC does not include a geographic or political region. A local time zone (for example, Central European Time) is defined as UTC plus or minus an offset and may include daylight saving rules.

    Link to cross-site KPI and calendar alignment

    When plants are in different time zones or follow different shift models and holidays, using UTC for underlying timestamps allows KPI calculations and reports to be normalized. Local definitions for runtime, downtime, or backlog can then be consistently aligned by converting each plant's local time data to UTC before aggregation or comparison.

  • Canonical time model

    A canonical time model is a standardized way of representing time-related data so different systems, applications, and records use the same structure and meaning. It commonly defines how timestamps, time zones, offsets, durations, intervals, and calendar references are formatted and interpreted when data moves between systems.

    In manufacturing and regulated operations, a canonical time model is used to reduce ambiguity when MES, ERP, historians, quality systems, equipment data sources, and reporting tools exchange time-based information. The goal is not to create a new clock source, but to create a common representation of time so events can be compared, sequenced, and traced reliably across systems.

    What it includes

    • Timestamp format, such as a consistent date-time pattern

    • Time zone handling, including whether times are stored in UTC, local time, or both

    • Offset rules, daylight saving treatment, and normalization conventions

    • Definitions for durations, elapsed time, shift time, and effective time windows

    • Business rules for event time, record creation time, update time, and system processing time

    What it does not mean

    A canonical time model is not the same as time synchronization itself. It does not guarantee that devices or applications are set to the same clock, and it does not replace protocols such as NTP or PTP. It also is not just a display format for dashboards. It is a data model and interpretation standard used so time values remain consistent across integrations and records.

    How it appears in operations

    Operationally, a canonical time model often appears in integration mappings, event schemas, data lake models, API contracts, historian connectors, and traceability records. For example, a machine event may be generated in local controller time, converted by an edge or middleware layer, and stored in a canonical format so MES, analytics, and quality systems all interpret the event consistently.

    This matters where sequence and timing affect production history, exception review, electronic records, downtime analysis, alarm handling, and genealogy. Common examples include aligning batch events, reconciling operator actions with equipment states, and comparing production timestamps across plants or regions.

    Common confusion

    Canonical time model is often confused with time synchronization. Time synchronization keeps clocks aligned. A canonical time model keeps time data represented consistently.

    It can also be confused with a data model more generally. A canonical data model may include many entities such as materials, orders, and equipment. A canonical time model is the part that standardizes time semantics within or across those entities.

    In analytics contexts, some teams use the term loosely to mean a standard reporting calendar. That is related, but narrower. A canonical time model usually covers machine-readable timestamps and event timing rules, not only fiscal or reporting periods.

  • Dimensional analysis

    Dimensional analysis is a method for working with physical quantities by expressing them in terms of fundamental dimensions such as length, mass, time, temperature, or electric current. It is commonly used to check whether an equation is dimensionally consistent, to convert or reconcile units, and to understand how variables may relate to one another in engineering and process work.

    In manufacturing and industrial settings, dimensional analysis often appears in process calculations, equipment specifications, utilities planning, environmental controls, and data validation. Examples include checking that a flow-rate calculation uses compatible units, confirming that a pressure drop formula resolves correctly, or translating values between measurement systems used by different equipment, suppliers, or software applications.

    It does not mean dimensional inspection of a part. Measuring whether a component meets drawing tolerances is a different activity in metrology and quality control, even though both use the word dimensional.

    What it includes

    • Checking that both sides of a physical equation have the same dimensions

    • Converting units such as inches to millimeters, psi to bar, or gallons per minute to liters per minute

    • Using dimensionless groups or scaling relationships in engineering analysis

    • Reviewing calculations in spreadsheets, MES-connected data models, or engineering records for unit consistency

    What it does not include

    • Geometric dimensioning and tolerancing (GD&T)

    • Routine part measurement, CMM inspection, or first article dimensional results

    • Statistical analysis by itself, unless physical units and dimensions are part of the evaluation

    Common confusion

    Dimensional analysis is commonly confused with dimensional inspection. Dimensional analysis focuses on units, dimensions, and physical relationships in calculations. Dimensional inspection focuses on whether a manufactured feature matches required size, form, or location tolerances.

    It can also be confused with simple unit conversion. Unit conversion is one part of dimensional analysis, but dimensional analysis is broader and includes checking equation structure and variable relationships.

  • Augmented Reality (AR)

    Augmented Reality (AR) is a class of technologies that overlay computer-generated information or graphics onto a user’s view of the real world in real time. In industrial and manufacturing environments, AR is commonly used through smart glasses, tablets, or smartphones to provide operators with contextual, step-by-step information while they look at actual equipment, parts, or workstations.

    How Augmented Reality is used in manufacturing

    In regulated and industrial operations, AR typically appears in workflows such as:

    • Visual work instructions: Overlaying assembly steps, torque values, or inspection points directly on the part or tool the operator is viewing.
    • Setup and changeover guidance: Highlighting which fixtures, tools, or machine settings are required for a specific work order.
    • Inspection and quality checks: Guiding inspectors to features, measurement locations, or defect examples on complex parts.
    • Maintenance and troubleshooting: Displaying schematics, procedures, or sensor data aligned to the physical asset during maintenance tasks.
    • Training and upskilling: Providing on-the-job guidance to less experienced operators while they perform real work on the shop floor.

    Operationally, AR solutions may be integrated with MES, ERP, PLM, or QMS systems so that the digital content shown (such as a work instruction version or inspection checklist) is tied to the current work order, revision, or configuration. In regulated settings, AR content often needs to follow the same document control, approval, and traceability practices as other controlled instructions.

    What Augmented Reality is not

    • AR is not the same as Virtual Reality (VR), which immerses users in a fully digital environment that replaces their view of the real world.
    • AR is not limited to entertainment or consumer use; in manufacturing it is typically a tool for guidance, visualization, and documentation support.
    • AR by itself is not a quality system or MES; it is an interface or presentation layer that may consume or display data from those systems.

    Common confusion

    AR vs. VR: Virtual Reality (VR) fully replaces the user’s environment with a simulated one, which is more common for off-line training or design reviews. Augmented Reality keeps the real environment visible and adds digital overlays, which is better suited to on-the-job use at a machine, bench, or inspection station.

    AR vs. Mixed Reality (MR): Mixed Reality is sometimes used to describe more advanced AR where digital objects appear anchored to the physical world with higher accuracy and may allow richer interaction. In many industrial contexts, AR and MR are used interchangeably in practice, with AR as the more general term.

    Relation to digital work instructions and MES

    In manufacturing, AR is often one way to deliver digital work instructions. Instead of reading steps on a fixed screen, operators see instructions, warnings, or measurements aligned to the workpiece or equipment. When connected to an MES, AR interfaces can:

    • Pull the correct instruction set for a specific part number, revision, or work order.
    • Record operator confirmations, measurements, or defect tags while tasks are performed.
    • Support traceability by associating AR-guided steps with time stamps, users, and serialized parts.

    Because AR content may affect how regulated processes are executed, organizations often treat AR overlays, models, and associated workflows as controlled documents or controlled software configurations within their quality and compliance frameworks.

  • UTC (Coordinated Universal Time)

    UTC (Coordinated Universal Time) is the primary global reference time standard used to keep timestamps consistent across locations, systems, and time zones. It provides a common baseline for recording events, synchronizing clocks, and exchanging time-based data.

    In manufacturing and regulated operations, UTC commonly appears in system logs, audit trails, equipment data, MES and ERP integrations, historian records, and data exchanged between sites in different local time zones. A timestamp stored in UTC can be converted for display in a user's local time zone without changing the original event time.

    UTC is not a local time zone. It does not change for daylight saving time, and it is not the same as a site's local operating time. It is also distinct from how time is displayed to users. For example, an event may be stored in UTC in a database but shown in Eastern Time or Central European Time in an application interface.

    Operational meaning

    • Used as a standard timestamp reference across plants, systems, and regions

    • Supports consistent sequencing of events in logs, alarms, transactions, and electronic records

    • Helps reduce ambiguity when integrating MES, ERP, SCADA, historians, LIMS, or quality systems

    • Commonly used in APIs, databases, cloud platforms, and machine-generated data

    Common confusion

    UTC vs GMT: These are often treated as equivalent in everyday use, but UTC is the modern time standard commonly used in technical systems.

    UTC vs local time: Local time includes a regional offset from UTC and may change with daylight saving rules. UTC itself does not.

    UTC vs time synchronization protocols: UTC is the reference time standard, while protocols such as NTP or PTP are methods used to synchronize devices and systems to a time source.

    In manufacturing systems

    Using UTC as the system-of-record time basis is common where traceability, cross-site reporting, or multi-system reconciliation matters. Examples include comparing machine events from different plants, aligning ERP transaction times with MES execution records, or reviewing audit trail entries generated by systems in different time zones.

  • hierarchy levels

    Hierarchy levels are structured layers used to describe how functions, systems, and data are organized within a manufacturing or industrial operation. They provide a common way to reference where activities occur, which systems are responsible, and how information flows from the enterprise level down to individual machines and equipment.

    Functional hierarchy levels in manufacturing

    In regulated and complex plants, hierarchy levels often follow industrial standards that separate business planning from manufacturing execution and physical control. A common model, aligned with IEC 62264 / ISA-95, includes:

    • Enterprise / Business level (often called Level 4 or above): Long-term planning, finance, customer orders, and supply chain management, typically managed by ERP and business systems.
    • Site / Plant level: Overall plant coordination, capacity planning, and site-wide performance management.
    • Area / Line / Cell level (often called Level 3): Manufacturing execution, sequencing, dispatching, detailed scheduling, quality recording, and traceability, typically managed by MES and related execution systems.
    • Process control level (often called Level 2): Automatic control of production processes, typically using SCADA, DCS, or PLC-based control systems.
    • Equipment / field level (often called Level 1 and 0): Sensors, actuators, tools, machines, and other physical devices that directly interact with materials and products.

    These levels are used to clarify which systems own certain data, where control decisions are made, and how responsibilities are divided between IT and OT.

    Use in metrics, KPIs, and integration

    Hierarchy levels are often referenced when defining and mapping manufacturing KPIs and data flows. For example, ISO 22400 KPIs such as Overall Equipment Effectiveness (OEE) or availability can be associated with specific hierarchy levels to show:

    • At which level the raw data is generated (for example, equipment or control level).
    • Which system calculates or aggregates the KPI (for example, MES at the area or line level).
    • Where the KPI is consumed for decisions (for example, enterprise or plant management level).

    In practice, engineering, IT, and operations teams use hierarchy levels to design system architectures, define interfaces between ERP, MES, and control systems, and document data ownership and responsibilities.

    Common confusion

    • Hierarchy levels vs. organizational hierarchy: Functional hierarchy levels describe systems and control responsibilities, not reporting lines or job titles.
    • Hierarchy levels vs. network layers: They are different from network models that describe how devices are connected. A control system and a business system may sit on similar networks but occupy different functional hierarchy levels.
    • Hierarchy levels vs. building layout: Physical plant layout (buildings, floors, and rooms) is separate from functional hierarchy, although both may use terms like “area” or “cell.”

    Context for aerospace and regulated environments

    In aerospace and other regulated industries, hierarchy levels are commonly used to document which level and which system is the system of record for production data, quality records, and traceability. When mapping standardized KPIs or compliance-related metrics, associating each metric with a hierarchy level helps clarify data provenance, validation responsibilities, and how evidence will be retrieved during audits.

  • event model

    An event model is a structured description of how events are represented, related, and stored in a system so that different applications can interpret, exchange, and analyze them consistently. In industrial and manufacturing environments, it commonly refers to the agreed format and rules for recording time-based occurrences such as equipment state changes, alarms, operator actions, and production milestones.

    Key characteristics

    A practical event model in manufacturing and OT/IT systems typically defines:

    • Event types (for example, equipment state change, alarm, production start/stop, quality decision).
    • Required attributes such as timestamps, resource identifiers, product or batch identifiers, and user or system source.
    • Optional attributes like reason codes, severity, duration, and links to related records (work orders, NCRs, maintenance orders).
    • Cardinality and rules, for example only one active equipment state event per resource at a time, or how overlapping events are handled.
    • Semantics, meaning how an event should be interpreted for KPIs, traceability, or workflows (e.g., which states count as “productive time” for OEE or ISO 22400 KPIs).

    Role in manufacturing and industrial systems

    In OT and MES/ERP-integrated landscapes, an event model provides a common language for:

    • Equipment and automation (PLC/SCADA) to report machine states and alarms in a normalized way.
    • MES and production systems to track operations, resource utilization, and shift performance based on time-stamped events.
    • Quality and compliance systems to link events to lots, batches, NCRs, or deviations for investigations and evidence trails.
    • Operations intelligence and KPIs such as OEE, non-productive time (NPT), and ISO 22400 metrics that depend on consistent state and timestamp logic.

    Event model vs data model

    An event model focuses on time-ordered changes and occurrences, while a general data model describes relatively static entities such as products, equipment, or bills of material. In many architectures, the data model defines what things exist, and the event model defines what happens to them and when.

    Common confusion

    • Event model vs message schema: A message schema (for example, a JSON or XML structure) defines the technical format of a single message. An event model is broader and covers event types, their relationships, sequencing rules, and interpretation for analytics and workflows.
    • Event model vs process model: A process model describes the intended sequence of activities or states. An event model describes the actual recorded occurrences that can later be compared against the process model.

    Relation to ISO 22400 KPIs and equipment states

    When implementing ISO 22400 manufacturing KPIs, an event model is often used to standardize how equipment state events are captured. This includes defining a unified set of states, ensuring only one active state per resource at a time, capturing precise start and end timestamps, and recording reason codes for state changes. Such a model allows vendor-specific SCADA or MES states to be normalized so that KPIs are calculated consistently across lines, plants, and systems.

  • EAM (Enterprise Asset Management)

    Enterprise Asset Management (EAM) is the discipline and supporting software used to plan, operate, maintain, and track physical assets across their full lifecycle. In industrial and manufacturing environments, it focuses on keeping equipment, facilities, and infrastructure reliable, compliant, and cost-effective from acquisition through decommissioning.

    What EAM includes

    In regulated manufacturing and industrial operations, EAM commonly includes:

    • Asset registry and hierarchy: Structured records of equipment, tools, facilities, and infrastructure, including IDs, locations, specifications, and ownership.
    • Preventive and predictive maintenance: Definition, scheduling, and tracking of work to reduce unplanned downtime and extend asset life.
    • Work management: Creation, assignment, execution, and closure of maintenance work orders, with time, labor, and material tracking.
    • Spare parts and MRO inventory: Control of maintenance, repair, and operations (MRO) parts and consumables linked to specific assets and work orders.
    • Asset performance tracking: Monitoring of uptime, failure history, repair times, and lifecycle costs to support decisions on replacement, overhaul, or redesign.
    • Compliance and documentation: Maintenance logs, calibration records, and inspection histories that support audits and regulatory requirements.

    Operational role in manufacturing systems

    In modern plants, EAM is typically implemented as a specialized software platform that connects with ERP, MES, and sometimes condition-monitoring or OT systems. Typical interactions include:

    • With ERP: Sharing asset master data, purchasing requests for spare parts, and financial information such as asset capitalization and depreciation (ERP) vs. operational health and maintenance history (EAM).
    • With MES: Exchanging equipment status, maintenance-related downtime codes, and maintenance work that affects production schedules and routings.
    • With quality and compliance systems: Providing evidence that equipment was maintained and calibrated when producing specific lots or serial numbers, often used in traceability and audit trails.

    For regulated sectors such as aerospace, defense, or life sciences, EAM records often support investigations, root cause analysis, and proof that production assets were maintained according to defined standards when critical parts were manufactured or repaired.

    What EAM is not

    • Not the same as ERP: ERP focuses on financials, procurement, and high-level planning. EAM focuses on the technical and operational side of asset health and maintenance execution.
    • Not strictly MES: MES manages production execution, work instructions, and WIP tracking. EAM manages the assets on which production runs, not the products being built.
    • Not only CMMS: A Computerized Maintenance Management System (CMMS) typically covers maintenance work management. EAM is broader, covering full asset lifecycle, performance, and integration with enterprise processes.

    Common confusion

    EAM vs CMMS: A CMMS usually centers on maintenance work orders and scheduling. EAM usually includes CMMS capabilities but adds asset lifecycle management, cost tracking, strategy optimization, and tighter integration with ERP and other enterprise systems.

    EAM vs APM (Asset Performance Management): APM often emphasizes analytics, condition monitoring, and predictive models for asset performance. EAM is the operational and administrative backbone that holds master data, maintenance history, and work execution records. In practice, EAM and APM may be separate tools that integrate, or capabilities within the same platform.

    Examples in regulated manufacturing

    • Tracking maintenance and calibration for critical machining centers used in aerospace part production, with records linked to specific serial numbers and work orders.
    • Managing overhaul cycles and component histories for assets used in MRO operations, such as test stands, ground support equipment, or specialized fixtures.
    • Coordinating planned maintenance windows with production schedules so that required inspections do not conflict with delivery commitments.