Connect981 – Content Dev

RSC Sphere: Data Integration, Security and Trust

The Data Integration, Security and Trust Sphere establishes the governance layer that makes everything else credible. It focuses on system interoperability, data mapping, version control, audit trails, and security alignment for regulated environments. The content makes clear how execution data can move safely across ERP, MES, QMS, PLM, and supplier systems without compromising control. This sphere proves that interoperability and security can coexist in aerospace ecosystems.

  • Workflow Configuration

    Workflow configuration commonly refers to the definition and setup of how a process moves through its steps in a software system or digital operation. It includes the rules, sequence, decision points, assignments, statuses, notifications, and data conditions that determine how work is created, routed, reviewed, approved, completed, or escalated.

    In manufacturing and regulated environments, workflow configuration often appears in MES, QMS, ERP-connected applications, document control systems, training systems, maintenance platforms, and nonconformance or CAPA processes. Examples include configuring approval paths for deviations, routing electronic work instructions by part or revision, assigning review tasks by role, or triggering holds when required data is missing.

    The term usually refers to setting up process logic inside a system, not performing the work itself. It also does not necessarily mean custom software development. Many platforms support workflow configuration through forms, business rules, status models, permissions, and low-code or no-code tools.

    What it typically includes

    • Process steps and status transitions

    • Role-based assignments and approvals

    • Entry and exit criteria for each stage

    • Business rules, validations, and conditional routing

    • Notifications, alerts, and escalation logic

    • Required records, attachments, or electronic signoffs

    • Links to master data, documents, equipment, or transactions in other systems

    Operational meaning

    Operationally, workflow configuration determines how a digital process behaves day to day. It affects who sees a task, what information is required, when a record can move forward, and what downstream actions are triggered. In integrated environments, workflow configuration may also govern handoffs between systems, such as sending order data from ERP to MES or moving quality events into CAPA review.

    Common confusion

    Workflow configuration is often confused with workflow design, process mapping, and software customization.

    • Workflow design defines the intended business process conceptually.

    • Workflow configuration implements that process behavior within a specific system.

    • Process mapping documents the flow, but does not by itself make the system enforce it.

    • Customization or development changes application code, while configuration usually uses built-in platform capabilities.

    The exact boundary varies by software platform, since some vendors use configuration to describe both rule setup and certain low-code extensions.

  • cloud service provider

    A cloud service provider is an organization that delivers computing resources over a network from shared cloud infrastructure. These resources can include servers, storage, databases, networking, applications, and security services that customers access remotely rather than operating on their own on-premises hardware.

    Scope and types of cloud service providers

    In industrial and manufacturing environments, cloud service providers commonly offer:

    • Infrastructure as a Service (IaaS): Virtual machines, storage, and networking used to host MES, data historians, or analytics platforms.
    • Platform as a Service (PaaS): Managed databases, event streams, and application platforms used to build custom manufacturing or quality applications.
    • Software as a Service (SaaS): Hosted applications such as quality management systems, electronic logbooks, maintenance systems, or production analytics tools.

    The provider owns and operates the underlying data centers, hardware, and core software platforms, and is responsible for base-level security, availability, and capacity of those services. Customers retain responsibility for how they configure, use, and validate those services within their regulated manufacturing processes.

    Operational meaning in regulated manufacturing

    In regulated industrial operations, a cloud service provider typically:

    • Hosts production, quality, engineering, and supply chain applications or data services used by plants and corporate teams.
    • Implements technical controls such as identity and access management, logging, encryption, and network segregation.
    • Provides audit logs, configuration options, and documentation that customers may use as part of their own validation, cybersecurity, and compliance programs.
    • May align with reference frameworks (for example, FedRAMP baselines or similar security programs) without removing the customer’s need for plant-level validation, integration testing, and supplier oversight.

    Cloud service providers are usually managed as critical suppliers or vendors, with contracts, service-level expectations, and security assessments governed by the manufacturer’s supplier management process.

    Common confusion

    • Cloud service provider vs. SaaS vendor: A SaaS vendor delivers a specific application over the cloud. That vendor may itself rely on another underlying cloud service provider for infrastructure.
    • Cloud service provider vs. hosting provider: Traditional hosting providers may offer fixed servers with limited self-service capabilities. Cloud service providers generally offer elastic, programmable infrastructure and standardized services (APIs, managed databases, etc.).

    Relation to security frameworks such as FedRAMP

    Some cloud service providers offer services that align with government or industry security frameworks. In manufacturing, these services are often selected for handling sensitive technical data, production records, or quality documentation. Such alignment usually indicates a defined set of security and control practices at the provider level, but it does not, by itself, establish compliance for a specific plant, product, or process. Organizations still need to perform their own risk assessments, validation, and ongoing oversight of the provider.

  • IT–OT convergence

    IT–OT convergence commonly refers to the intentional integration and coordination of information technology (IT) systems with operational technology (OT) systems in industrial and manufacturing environments. It focuses on treating business information systems and plant-floor control systems as a connected ecosystem rather than separate technology stacks.

    What IT–OT convergence includes

    In regulated and industrial operations, IT–OT convergence typically includes:

    • Connecting enterprise IT systems (such as ERP, PLM, LIMS, and quality systems) with plant-floor OT systems (such as PLCs, DCS, SCADA, historians, and MES).
    • Aligning data models, standards, and interfaces so production, quality, maintenance, and business data can be exchanged and used consistently.
    • Coordinating governance, cybersecurity policies, and change control across both IT and OT environments.
    • Implementing shared architectures and platforms, for example using industrial networks, edge computing, and secure gateways to bridge plant and enterprise networks.
    • Defining joint roles and responsibilities for IT and OT teams, including support, incident response, and lifecycle management for shared systems.

    IT–OT convergence is not a single product or standard. It is a combination of architecture, integration approaches, and organizational practices that connect technology and data across traditional IT and OT boundaries.

    Operational meaning in manufacturing

    At an operational level, IT–OT convergence shows up in activities such as:

    • Integrating MES and ERP so production orders, material data, and quality results flow automatically between business and shop-floor systems.
    • Streaming data from sensors, controllers, and historians into analytics, reporting, and operations-intelligence platforms managed by IT.
    • Applying unified access control, patching, backup, and monitoring practices to both servers in the data center and industrial devices on the plant floor, with appropriate OT-specific constraints.
    • Supporting traceability and genealogy requirements by combining equipment event data with batch records, electronic device history records, or electronic batch records.

    Common confusion

    IT–OT convergence is often discussed alongside related concepts:

    • Industry 4.0 / smart manufacturing: IT–OT convergence is one enabling aspect of these initiatives but is more specific, focusing on how IT and OT systems and teams connect and collaborate.
    • IIoT (Industrial Internet of Things): IIoT emphasizes connected devices and data collection. IT–OT convergence is broader and includes governance, organizational integration, and enterprise-to-plant processes, not just device connectivity.
    • Network convergence: Combining IT and OT networks is one technical element of IT–OT convergence, but the term also covers applications, data, security practices, and organizational alignment.

    Relevance in regulated and compliant environments

    In regulated manufacturing, IT–OT convergence is closely linked to topics such as:

    • Data integrity and consistent handling of electronic records across enterprise and plant-floor systems.
    • Coordinated cybersecurity controls for both IT and OT assets, often aligned with industrial security standards.
    • Change management and validation practices that span MES, ERP, control systems, and interfaces between them.
    • Audit readiness, where evidence may rely on data and logs from both IT and OT systems.

    When planned and governed appropriately, IT–OT convergence provides a structured way to treat industrial control systems and enterprise information systems as parts of a single, managed operational ecosystem.

  • What is the ISA-95 standard?

    ISA-95 (also published internationally as IEC 62264) is a standard that provides models and terminology for integrating business systems with manufacturing operations and control systems. It is widely used to structure how ERP, MES, SCADA, historians, and shop-floor controls exchange information and responsibilities.

    What ISA-95 actually defines

    ISA-95 focuses on models and interfaces, not specific software products. Key elements include:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • Functional levels: A layered view from field control (Level 0–2), through manufacturing operations management (Level 3, typically MES/LIMS/WMS), up to business planning and logistics (Level 4, typically ERP).
    • Functional models: Standardized descriptions of what activities belong at each level, such as production scheduling, dispatching, data collection, quality operations, and maintenance operations.
    • Information models: Common structures for things like material definitions, equipment models, work definitions (recipes/routings), production schedules, production performance, and personnel.
    • Object and attribute naming: Standardized ways to describe entities such as products, equipment, physical assets, and work operations so that different systems can reference the same thing consistently.

    The intent is to give IT, engineering, and operations teams a shared language for what information should move between systems, where responsibilities sit, and how data should be modeled.

    What ISA-95 does not do

    In regulated, brownfield environments, it is important to be explicit about what ISA-95 does not provide by itself:

    • No automatic compliance: Using ISA-95 terminology or models does not create or guarantee regulatory compliance, audit outcomes, or data integrity. Those depend on your specific processes, controls, and validation activities.
    • No plug-and-play interoperability: Two vendors can both claim “ISA-95 compatibility” yet still require significant custom integration, data mapping, and testing. The standard narrows ambiguity, but it does not remove integration effort.
    • No full architecture prescription: ISA-95 does not mandate a particular system topology, vendor stack, or cloud/on-prem split. It frames what functions and data are needed, not exactly how to implement them.
    • No validation or qualification: Validation, qualification, and change control remain site responsibilities. ISA-95 can support traceability and clearer specifications, but it is not a validation framework.

    Why ISA-95 matters in industrial and regulated environments

    For organizations running mixed-vendor MES, ERP, historians, and control systems over long asset lifecycles, ISA-95 is mainly useful as a structuring and communication tool:

    • Clear system boundaries: It helps define which system should own which function (for example detailed scheduling in MES vs. rough-cut planning in ERP) and reduces overlap and ambiguity over time.
    • More robust integration design: Information models give a starting point for specifying interfaces, payloads, and data flows between systems. This can reduce misinterpretation and rework during integration projects.
    • Traceability and data governance: A consistent model for equipment, materials, and work definitions makes it easier to understand where critical records originate, how they transform, and how they are consumed across systems.
    • Change control over long lifecycles: When equipment and systems stay in place for decades, the standard’s models create a stable reference that survives vendor changes, interface rewrites, and incremental upgrades.

    How ISA-95 fits with existing (brownfield) systems

    In most plants, ISA-95 is applied into an existing landscape rather than starting clean. Typical patterns include:

    • Mapping current systems to ISA-95 levels: Identify which capabilities are actually provided by which existing systems, and where functions are duplicated or missing.
    • Using ISA-95 models to design integrations: When creating or refactoring interfaces (for example, between ERP and MES), use ISA-95 entities like production schedule, material definition, and production performance as the conceptual contract, then map to each system’s actual data structures.
    • Incremental alignment: Rather than replacing legacy MES or ERP solely to “be ISA-95 compliant,” teams gradually standardize interfaces and naming, usually in parallel with other projects (such as new lines, new products, or historian upgrades).
    • Documenting architecture and responsibilities: Architecture documents, URSs, and interface specifications often use ISA-95 terms to make responsibilities and data flows auditable, especially where different vendors or internal teams share ownership.

    Full replacement of legacy systems just to align with ISA-95 is rarely justified in high-regulation settings because of qualification burden, downtime risk, and integration complexity. ISA-95 is usually more valuable as a reference model to guide staged improvements.

    Relationship to other standards and practices

    ISA-95 often appears alongside other frameworks:

    • MES reference models: Many MES vendors structure their functional capabilities and data models directly on ISA-95, especially for production, quality, maintenance, and inventory operations.
    • Enterprise integration patterns: ISA-95 describes what is exchanged conceptually. Technical integration patterns (APIs, message buses, OPC UA, file-based transfers) define how those models are implemented and governed.
    • Data modeling and master data: ISA-95 models can support master data management efforts by clarifying common entities like materials, equipment, resources, and routings across ERP, PLM, and MES.

    Practical limitations and failure modes

    Common challenges when using ISA-95 include:

    • Partial adoption: Plants may adopt the level model but ignore information models, leading to ambiguous data contracts and confusion despite “ISA-95” labels.
    • Over-interpretation: Treating ISA-95 as a rigid rulebook can conflict with real-world constraints, such as legacy controllers or validated workflows that cannot be easily restructured.
    • Vendor interpretation gaps: Different vendors interpret the standard differently. Interface specification and testing remain crucial, even when all parties claim ISA-95 alignment.
    • Underestimated integration work: Assuming that “ISA-95 compliant” systems will integrate with minimal effort often leads to schedule slips. Detailed mapping, transformation rules, and validation tests are still required.

    Used thoughtfully, ISA-95 is a stable reference model that helps structure integration, clarify system roles, and support long-term maintainability. Its value depends on how rigorously it is applied in architecture, specifications, and change control, not on labels alone.

  • What are the 4 categories of security controls?

    In most industrial cybersecurity and information security frameworks, security controls are commonly grouped into four practical categories:

    1. Physical controls

    Physical controls prevent or limit physical access to facilities, equipment, and infrastructure. In manufacturing and regulated environments, this typically includes:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Badged access to production areas, server rooms, and critical test labs
    • Locks, cages, and safes for network cabinets and media
    • Video surveillance and environmental monitoring (e.g., for tamper or intrusion)
    • Segregated areas for export-controlled or ITAR-sensitive activities

    These controls depend heavily on site layout, legacy building infrastructure, and how well physical access systems are integrated with HR, visitor management, and change control processes.

    2. Technical (logical) controls

    Technical controls use technology to enforce security requirements on systems, networks, and data. Typical examples in brownfield manufacturing environments include:

    • Network segmentation and firewalls between OT, MES, ERP, and corporate IT networks
    • Authentication, authorization, and role-based access control for MES, QMS, PLM, and SCADA
    • Endpoint protection, application whitelisting, and secure configuration baselines
    • Encryption for data in transit between plants and data centers or cloud services
    • Logging, monitoring, and SIEM integrations for critical systems

    The effectiveness of technical controls depends on integration quality, asset inventory accuracy, and whether legacy equipment can support modern security mechanisms without disrupting validated or qualified configurations.

    3. Administrative (procedural) controls

    Administrative controls are policies, procedures, and governance mechanisms that define how people should design, operate, and maintain systems. In regulated industrial settings, these typically include:

    • Access provisioning and de-provisioning procedures tied to HR and training records
    • Change control and configuration management for OT, MES, QMS, and automation systems
    • Vendor and remote access procedures, including temporary access and monitoring
    • Incident response plans coordinated across IT, OT, quality, and operations
    • Training and awareness on handling controlled technical data and production records

    These controls are only effective if they are documented, followed in daily operations, and aligned with regulatory expectations for traceability, validation, and auditability.

    4. Compensating controls

    Compensating controls are alternative safeguards put in place when a preferred or “standard” control cannot be implemented, often due to legacy equipment, validation constraints, or downtime risk. Examples include:

    • Enhanced physical access controls and camera coverage when legacy OT devices cannot be patched promptly
    • Strict procedural workarounds (e.g., dual signoff, manual checks) when a system lacks fine-grained access control
    • Network isolation and tightly controlled jump hosts for equipment that cannot support endpoint protection agents
    • Additional monitoring and logging when encryption or protocol changes would require costly requalification

    Compensating controls should be documented, risk-justified, and periodically reviewed. In regulated environments, they must be clearly traced in risk assessments and change records, and they do not remove the underlying obligation to address the primary risk when feasible.

    How this plays out in brownfield, regulated plants

    In mixed vendor, long-lifecycle environments, you typically rely on all four categories working together. Full replacement of legacy systems purely for security reasons is often impractical due to qualification and validation burdens, integration complexity, and downtime risk. As a result:

    • Physical and administrative controls are frequently strengthened to compensate for technical gaps in legacy assets.
    • Technical controls are layered at the network or gateway level when device-level controls are not possible.
    • Compensating controls become a formal part of your documented risk treatment, with clear traceability for audits.

    When designing or assessing your control set, it is important to classify controls in these four categories explicitly, document dependencies and limitations, and ensure that changes to any one control are managed through appropriate change control and revalidation where required.

  • What is Industry 4.0 in simple terms?

    Industry 4.0 is a shorthand for using connected, data-driven technologies to run manufacturing and supply chains more intelligently. In simple terms, it is:

    “Connecting machines, people, and systems so data flows in real time and software can help decide what to do next.”

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Core ideas in practical terms

    In an industrial, regulated environment, Industry 4.0 usually shows up as:

    • Connected equipment: Machines, tools, and sensors that send data (status, parameters, alarms, usage) into your plant network and systems.
    • Integrated systems: MES, ERP, QMS, PLCs, historians, and lab systems exchanging data instead of living in silos.
    • Digital workflows: Work instructions, deviations, approvals, and change records managed in software with traceability.
    • Analytics and automation: Using collected data for monitoring, forecasting, optimization, or closing certain loops automatically (with defined limits and controls).
    • Human-in-the-loop decisions: Operators, supervisors, quality, and engineering getting better, more-timely information rather than being replaced.

    What Industry 4.0 is not

    • It is not a single product you can buy. It is a combination of technologies and process changes.
    • It is not a guarantee of compliance, audit success, or safety. Those still depend on process design, validation, and governance.
    • It is not an overnight “smart factory” transformation. In brownfield plants, progress is incremental and constrained by legacy systems and qualification requirements.

    How this works in a brownfield, regulated plant

    In most regulated and long-lifecycle environments, Industry 4.0 looks like layering capabilities onto what you already have, for example:

    • Adding condition monitoring sensors to legacy machines instead of replacing the machines.
    • Integrating MES with QMS and ERP so deviations, lots, and orders line up automatically.
    • Replacing paper travelers and work instructions with digital versions tied to revision control and electronic signatures.
    • Using a historian or data platform to combine process data, quality results, and maintenance history for analysis.

    Full replacement strategies often fail or stall because they require long downtime, re-validation of entire lines, retraining, and re-integration with existing systems. As a result, most plants pursue Industry 4.0 as a controlled, stepwise program rather than a single big-bang change.

    Key constraints and tradeoffs

    • Traceability and validation: Any new digital connection or automation that affects product or records must be validated and governed under change control.
    • Integration complexity: Connecting multiple vendors’ MES/ERP/QMS/PLM systems and legacy equipment can be harder than deploying the new tool itself.
    • Downtime risk: Aggressive upgrades or replacements can threaten output commitments and regulatory commitments if they fail.
    • Data readiness: Benefits from advanced analytics or AI depend on data completeness, quality, and clear ownership. Many plants need basic data hygiene before advanced use cases pay off.

    In simple terms: Industry 4.0 is about making your existing manufacturing system more connected, observable, and data-driven, under the realities of regulation, validation, and long-lived assets.

  • What is the best way to integrate MES with existing special process equipment?

    There is no single “best” integration pattern

    There is no universal best way to integrate MES with special process equipment in regulated environments. The viable integration pattern depends on the specific equipment generation, available interfaces, control system architecture, and the level of automation your quality system can realistically support and validate. In practice, plants end up with a mix of approaches: some equipment is tightly integrated, some is loosely coupled via gateways, and some remains largely manual with procedural controls. The goal is usually controlled, traceable data exchange with minimal disturbance to qualified equipment, not maximal automation at any cost.

    Start from requirements, not from the interface

    The first step is to define what the integration must achieve before deciding how to connect anything. Common MES requirements include electronic batch record parameters, recipe enforcement, equipment status, alarms, and lot/serial traceability. In regulated settings you also need to decide which values are “record” data (subject to data integrity rules) and which are advisory or diagnostic. This requirement set should be aligned with quality, operations, and validation to avoid building interfaces that are technically impressive but not defensible in audits. Only once the required data, timing, and controls are clear does it make sense to evaluate which integration pattern is appropriate for each equipment type.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Prefer non-invasive integration with legacy special process equipment

    Special process equipment in aerospace, pharma, or similar environments is often heavily qualified and expensive to revalidate. Directly modifying PLC code, HMI logic, or internal data structures to support MES integration can trigger major requalification, extended downtime, and regression risk. A more sustainable starting point is non-invasive integration: using existing vendor-supported protocols, read-only data taps, or approved export mechanisms. Where possible, keep integration at the boundary of the system (e.g., OPC UA server, historian interface, file drop) instead of altering control logic. This reduces the change-control burden and helps avoid unplanned rework when audits scrutinize how the interface was implemented.

    Use edge gateways and standard protocols where feasible

    For mixed-vendor environments, an edge gateway that speaks multiple industrial protocols can provide a stable integration layer between MES and equipment. Gateways can aggregate data from PLCs, instruments, and vendor-specific interfaces, then expose it to MES via a standardized protocol such as OPC UA or via validated APIs. This approach reduces the need to customize MES for each equipment type and can isolate MES from low-level control changes. However, gateways introduce another component to validate and maintain, so their configuration, firmware, and data mappings must be controlled under change management. Performance, time synchronization, and buffering behavior also need to be characterized so the MES does not misinterpret transient states as permanent conditions.

    Consider the limits of direct MES–equipment integration

    Direct MES-to-equipment interfaces can be attractive where the vendor provides a supported API or MES connector, especially on newer systems. The upside is cleaner, often better-documented integration with vendor support for upgrades. The downside is tight coupling: MES changes and equipment software changes can interact in unexpected ways and may both require revalidation. In addition, vendor APIs sometimes expose only a subset of what operations wants, leading to custom workarounds that are harder to sustain. Before adopting direct interfaces broadly, it is important to assess how often equipment software is updated, how the vendor manages backward compatibility, and how your plant will handle parallel upgrades without disrupting production.

    Define a clear separation of responsibilities between MES and control

    For special processes, it is risky to let MES directly control critical parameters in real time, especially over non-deterministic networks. A more robust pattern is to let MES own what to run (recipe, limits, approvals, genealogy) and let the control system own how to run it (low-level loops, interlocks, safety). In this pattern, MES passes approved parameters to the equipment, the control system enforces those parameters, and then returns executed results and deviations back to MES. This separation keeps safety and basic control in deterministic, validated controllers, while MES provides traceability and enforcement of procedural rules. It also reduces the risk that a MES upgrade could unintentionally compromise a safety function or core process capability.

    Plan explicitly for data integrity, time alignment, and failure modes

    In regulated environments, integration is not just about connectivity; it is about reliable, reconstructable event histories. Interfaces should be designed so that each data point or event can be traced to its source, timestamped consistently, and associated with the correct batch, lot, or work order. You need to define what happens when networks fail, buffers overflow, or equipment runs while MES is unavailable. For example, you may need queued data with signatures, local buffering on gateways, or procedural fallback modes where operators capture key data manually until connectivity is restored. These choices must be documented, risk-assessed, and aligned with your quality system so that gaps in automated capture do not invalidate entire batches or build records.

    Avoid full replacement strategies just to achieve integration

    Replacing older special process equipment purely to enable a modern MES interface is rarely justifiable in aerospace-grade or similar regulated environments. The costs and risks include long downtime, extensive qualification and validation, rework of existing methods, and integration re-engineering with other systems such as PLCs, SCADA, historians, and QMS. Moreover, new machines can introduce different failure modes, learning curves, and unanticipated defects that offset any short-term integration gains. A more realistic approach is to incrementally enhance integration around existing assets, retiring or replacing equipment only when there is a clear process, quality, or capacity justification beyond connectivity alone. Where replacements are necessary, plan integration, qualification, and MES changes as a single, tightly controlled program instead of a series of isolated projects.

    Tie integration strategy to your plant’s process maturity

    The most appropriate integration level also depends on how mature your processes and data governance are. Plants with unstable routing, frequently changing specifications, or inconsistent master data often struggle to sustain tight integrations because interfaces must be revised every time upstream definitions change. In such cases, starting with focused, high-value integrations—such as automated capture of critical parameters or pass/fail results—can deliver benefit without overwhelming change control. As master data, procedures, and governance stabilize, you can expand integration scope and move more logic from paper or spreadsheets into MES. This staged approach aligns integration complexity with your organization’s ability to maintain and defend it under audit.

  • Entity model

    An entity model is a structured representation of the key business objects in a domain, the data each object holds, and how those objects relate to one another. In manufacturing and industrial software, it commonly describes items such as materials, equipment, work orders, operations, batches, personnel, suppliers, and quality records.

    The purpose of an entity model is to define what the system treats as distinct entities and how information is organized around them. It is used in databases, application design, integrations, analytics, and reporting. A well-defined entity model helps different systems refer to the same real-world objects in a consistent way.

    An entity model usually includes:

    • Entities: the core objects being tracked, such as a part, machine, lot, or production order

    • Attributes: the properties of each entity, such as part number, revision, status, timestamp, or serial number

    • Relationships: how entities connect, such as a work order consuming materials, or a batch being produced on a specific line

    How it appears in operations systems

    In MES, ERP, PLM, QMS, and related platforms, the entity model shapes how data is stored and exchanged. For example, if a system defines product, routing, operation, and inspection result as separate entities, integrations and reports can link those records more clearly. This matters for traceability, genealogy, scheduling, deviation handling, and audit evidence assembly.

    Entity models are also important in system integration. When two systems use different entity models, mapping is needed so that one system’s object structure can be interpreted correctly by the other. For example, one platform may treat a batch as the main production entity, while another centers on serial numbers or work orders.

    What it includes and excludes

    An entity model includes the logical structure of business data and relationships. It does not by itself define screen layouts, process steps, user permissions, or physical database performance tuning, although those may be built on top of it.

    It also does not necessarily specify every rule for how data changes over time. Those rules may be handled separately in workflows, state models, business rules, or application logic.

    Common confusion

    Entity model vs. data model: An entity model is often a type of conceptual or logical data model focused on business objects and their relationships. In practice, some teams use the terms interchangeably, but a full data model may go further into technical structures such as keys, data types, and normalization.

    Entity model vs. object model: In software engineering, an object model may include behavior and methods as well as structure. An entity model usually focuses on the data entities themselves.

    Entity model vs. process model: A process model describes workflow, sequence, or activity flow. An entity model describes the things the process acts on.

    Manufacturing example

    A simple manufacturing entity model might define material, lot, work order, operation, equipment, operator, nonconformance, and inspection record as separate entities, with relationships showing which lot was used on which work order, on what equipment, and with which resulting quality records.

  • raw data

    Raw data commonly refers to unprocessed values captured directly from a source, such as sensors, machines, operator inputs, or IT/OT systems, before those values are cleaned, transformed, aggregated, or interpreted.

    What raw data includes

    In industrial and manufacturing environments, raw data typically includes:

    • Time-stamped sensor readings (for example, temperature, pressure, speed)
    • Machine status codes and event logs from PLCs, SCADA, or MES
    • Unaggregated production counts, scrap counts, and cycle times
    • Operator entries such as checklists, comments, or manual measurements
    • Transaction-level records from MES, ERP, LIMS, or quality systems

    Raw data is usually stored in historians, databases, log files, or message streams before any significant business logic is applied.

    What raw data does not include

    Raw data does not include values that have been substantially processed or interpreted, such as:

    • Indicators that combine multiple raw data points into a single derived metric
    • Key performance indicators (KPIs) such as OEE, on-time delivery, or defect rate
    • Aggregated reports (for example, hourly, shift, daily summaries)
    • Statistical calculations like averages, control limits, or capability indices

    Once rules, calculations, or contextual enrichment are applied, the result is no longer considered raw data, even if the original values are retained.

    Operational role in manufacturing systems

    In OT and IT environments, raw data is the foundation for monitoring, analysis, and compliance activities. It is:

    • The input to indicators and KPIs used in performance dashboards and reports
    • The evidence base for traceability, genealogy, and deviation investigations
    • The feedstock for advanced analytics, such as predictive maintenance models
    • A key element of data integrity and audit trails in regulated operations

    Effective governance often distinguishes raw data from transformed data so that users understand which values are directly measured and which are calculated or modeled.

    Relation to ISO 22400 concepts

    In the context of ISO 22400, raw data corresponds to basic measurements captured from equipment and systems. These measurements can then be transformed into indicators by adding calculations or context, and a subset of those indicators may be designated as KPIs for operational or business decision-making. The standard emphasizes structural distinctions but does not, by itself, guarantee how any site defines or governs its raw data.

    Common confusion

    • Raw data vs. indicators: Indicators typically aggregate or calculate values from raw data and may include business rules or contextual information, while raw data remains as-captured.
    • Raw data vs. logs: Logs are often collections of raw data, but a log file may also contain derived or formatted entries; individual log entries can still be raw data if they directly reflect unprocessed measurements or events.
    • Raw data vs. cleansed data: Once data has been filtered, corrected, or normalized, it is no longer strictly raw, even if it retains the same basic structure as the original measurements.

  • brownfield environments

    Brownfield environments are existing industrial sites, facilities, or systems that are already built and in operation, where new equipment, automation, or software must be integrated into what is already there. In manufacturing, this typically includes legacy OT assets, established production lines, installed control systems, and supporting IT infrastructure that cannot simply be replaced.

    In contrast to greenfield projects, which start from a clean slate, brownfield work focuses on modifying, extending, or upgrading current systems while production, quality, and compliance obligations continue.

    Key characteristics in industrial and regulated settings

    • Existing assets and constraints: Legacy PLCs, DCS, SCADA, MES, and custom integrations that may have limited documentation or vendor support.
    • Continuous operations: Changes must be implemented around live production schedules and validation needs, often with tight maintenance windows.
    • Mixed technology generations: Old and new hardware, operating systems, networks, and applications must coexist securely and reliably.
    • Regulatory and quality impact: Modifications may trigger requalification, revalidation, or updates to procedures, records, and training.
    • Physical and network limitations: Existing layouts, cable routes, panels, and IP schemes restrict how new systems can be deployed.

    Operational meaning

    In practice, working in a brownfield environment affects how organizations plan and execute initiatives such as:

    • Introducing new OT security controls or segmenting existing networks.
    • Integrating new MES or historian systems with legacy controllers and databases.
    • Upgrading plant-floor equipment while maintaining validated states in regulated plants.
    • Applying supply chain and procurement controls for replacement parts and vendors when original suppliers are no longer available.

    Engineering, IT, quality, and operations teams typically need coordinated change control, impact assessment, and testing strategies that account for installed base variability and historical configurations.

    Common confusion

    • Brownfield vs. greenfield: Greenfield environments are new builds with no existing production or systems to integrate with. Brownfield involves modification of existing, running facilities.
    • Brownfield site (environmental) vs. operational brownfield: Outside industrial operations, “brownfield” can also refer to land with prior industrial use and possible contamination. In manufacturing systems and OT/IT discussions, the term more often refers to existing plants and installed systems, not environmental remediation status.

    Relation to supply chain and risk controls

    In frameworks such as NIST SP 800-53, brownfield environments influence how supply chain and cybersecurity controls are applied. For example, controls on vendor selection, component authenticity, and system integrity must be adapted to replacement parts, upgrades, and integrations into an existing installed base rather than only to new greenfield projects.