Connect981 – Content Dev

RSC Content Type: Explainer Brief

Short, high-clarity breakdown of a specific term or mechanism.

  • design change

    A design change is a controlled modification to an approved product, component, software, or system design. It typically alters one or more design artifacts such as drawings, models, specifications, bills of material, software code, or interface definitions, and is managed through a formal engineering and configuration control process.

    Scope and characteristics

    In industrial and regulated manufacturing environments, a design change generally includes:

    • Updates to engineering drawings, 3D models, or CAD data
    • Revisions to requirements, specifications, or performance criteria
    • Changes to materials, components, or part geometry
    • Software or firmware updates that affect function, safety, or interfaces
    • Configuration changes to assemblies, systems, or product variants

    A design change is differentiated from routine process adjustments because it affects what the product is, not just how it is built. It is normally documented via engineering change requests (ECRs), engineering change orders (ECOs), deviation or concession processes, or similar mechanisms within PLM, PDM, or QMS systems.

    Operational meaning in manufacturing

    Operationally, design changes trigger coordinated updates across multiple systems and workflows, for example:

    • Revising controlled documents such as drawings, specifications, and work instructions
    • Updating BOMs and routing in ERP/MES to reflect new parts or operations
    • Adjusting inspection plans, FAI packages, and quality records
    • Assessing impact on tooling, fixtures, NC programs, and test equipment
    • Updating maintenance, overhaul, and repair instructions in MRO environments

    In standards such as AS9100 and similar quality frameworks, design changes are expected to be risk-assessed, reviewed, approved by authorized functions, and fully traceable. This includes clear identification of affected configurations, effective dates or serial/batch cut-ins, and linkage to verification and validation evidence.

    Design change and risk management

    In regulated sectors like aerospace and defense, design change is closely tied to risk management and configuration control. Typical practices include:

    • Evaluating potential impacts on safety, reliability, and compliance before approval
    • Reviewing downstream effects on suppliers, fielded assets, and MRO organizations
    • Ensuring alignment between design data in PLM and execution data in MES/ERP
    • Maintaining an audit trail of rationale, approvals, and implementation status

    For in-service products, design changes may drive service bulletins, retrofit campaigns, or updated maintenance instructions, and must be coordinated with continuing airworthiness and configuration management of fielded units.

    What a design change is not

    To avoid confusion, a design change usually does not include:

    • Minor shop-floor process tweaks that do not affect fit, form, function, or approved requirements
    • Temporary repair deviations or concessions applied to individual units without altering the baseline design
    • Administrative document edits that do not modify technical content

    However, if a process or repair change alters product requirements, interfaces, or performance, it often must be promoted and controlled as a formal design change.

    Common confusion

    • Design change vs. process change: A design change affects the product definition (what is built). A process change affects how the approved design is manufactured or inspected. In practice they interact, but they should be controlled and documented distinctly.
    • Design change vs. configuration change: A configuration change is any modification to the defined state of a product or system. A design change is one of the main mechanisms that drives configuration changes and updates the controlled baseline.
    • Design change vs. deviation/concession: A deviation or concession typically allows a one-time or limited departure from design requirements for specific units. A design change modifies the requirements themselves for future units or configurations.

  • Business Impact

    Business impact commonly refers to the measurable effect that an event, decision, change, failure, or risk has on an organization’s ability to achieve its objectives. In industrial and regulated manufacturing environments, it focuses on how operations, quality, compliance, financial performance, and reputation are affected.

    Core meaning

    In an operational and risk context, business impact typically includes:

    • Operational impact: Disruption to production, schedules, throughput, or delivery commitments.
    • Financial impact: Direct costs (scrap, rework, downtime, expedited freight) and indirect costs (lost margin, penalties, lost opportunities).
    • Quality and compliance impact: Effects on product quality, batch release, deviations, recalls, or regulatory findings.
    • Customer and market impact: Effects on service levels, lead times, contract performance, and reputation.
    • Information and cybersecurity impact: Consequences of data loss, OT/IT incidents, or system unavailability on safe and compliant production.

    Business impact is usually expressed in quantitative terms (cost, time, volume, likelihood) or with defined impact levels (for example: minor, moderate, major, critical) within a risk or change framework.

    Use in manufacturing workflows

    In manufacturing systems and governance processes, business impact often appears as a required field or assessment step, for example:

    • Risk assessments and business impact analysis (BIA): Evaluating how loss of a process, system, or supplier would affect production, compliance, and safety-critical obligations.
    • Change control: Classifying and approving changes to equipment, recipes, MES, ERP, or procedures by assessing their potential business impact.
    • Incident and deviation management: Determining the impact of quality events, OT/IT outages, or nonconformances on product, batches, and customers.
    • Prioritization of work: Using impact scores to prioritize CAPA, maintenance, upgrades, or cybersecurity hardening activities.

    Business impact vs. related concepts

    • Business impact vs. risk: Risk combines the likelihood of an event with its impact. Business impact focuses on the consequence side only, assuming the event occurs.
    • Business impact vs. root cause: Root cause explains why something happened. Business impact describes what that event did to the business.
    • Business impact vs. criticality: Criticality is a property of an asset, process, or system (how important it is). Business impact is the effect when that asset, process, or system is disrupted or changed.

    Common confusion

    The term is sometimes used loosely as a synonym for “importance” or “priority.” In formal risk management, change control, and business continuity planning, business impact should be tied to specific, documented effect types (such as production loss, regulatory exposure, or contractual breach) and to defined impact scales.

  • manufacturing router

    A manufacturing router is a structured definition of the steps, resources, and rules used to produce a part, assembly, or product. It describes the planned path of work through a manufacturing facility, typically including operation sequences, work centers, standard times, required tools, and inspection or testing points.

    In many systems the router is a master data object stored in an ERP, MES, or similar system. It is used to generate work orders, schedule operations, calculate capacity and cost, and drive shop floor instructions and travelers. In regulated industries, the router often links to controlled work instructions, drawings, and inspection plans to support traceability.

    Typical contents of a manufacturing router

    Although formats vary by system and industry, a manufacturing router commonly specifies:

    • A list of operations in the required sequence (e.g., cut, machine, treat, inspect, assemble)
    • Assigned work centers, machines, or cells for each operation
    • Planned or standard times (setup time, run time, queue or move time)
    • Required tools, fixtures, materials, and special process notes
    • Quality and inspection steps, including in-process checks and first article requirements
    • References to controlled documents such as work instructions, drawings, and specifications
    • Routing rules or alternates (e.g., alternate work centers, rework routes)

    Routers may exist at different levels of detail, such as high-level routings in ERP for costing and capacity, and more granular routings or digital travelers in MES that guide actual execution on the shop floor.

    Operational role

    Operationally, the manufacturing router is the backbone of how work moves through a plant. It is used to:

    • Create work orders and travelers for specific jobs or lots
    • Drive scheduling, dispatching, and load planning for work centers
    • Record actual start/finish times and yields against each operation
    • Link inspection, test, and first article activities to specific operations
    • Support genealogy and traceability by defining the expected process path

    In aerospace and other regulated environments, changes to a manufacturing router are often controlled through formal change processes and may trigger activities such as partial or delta first article inspections when operations or characteristics are affected.

    Common confusion

    • Manufacturing router vs. traveler/route card: The router is the master definition of the process. A traveler or route card is the job-specific or lot-specific instance derived from the router that accompanies the work through the plant.
    • Manufacturing router vs. work instruction: The router defines which operations are performed, where, and in what order. Work instructions provide the detailed, step-by-step guidance on how to perform a particular operation defined in the router.
    • Network router vs. manufacturing router: In IT, a router is a networking device that directs data traffic. In manufacturing, a router refers to the process routing for parts and products, not a piece of network hardware.

  • PII

    PII, or Personally Identifiable Information, commonly refers to any information that can be used to identify a specific individual, either directly or in combination with other data. In industrial and regulated manufacturing environments, PII most often appears in HR systems, training records, access control logs, supplier contact data, and engineering or quality workflows that reference specific people.

    What PII typically includes

    PII generally includes, but is not limited to:

    • Direct identifiers such as full name, government-issued identification numbers, employee IDs, email addresses, phone numbers, and physical addresses
    • Authentication or account information tied to a person, such as usernames when linked to an identifiable individual
    • Personnel-related records, including performance reviews, shift schedules, time and attendance data, and training records when associated with a named person
    • Any other data elements that, alone or combined, can reasonably identify a specific person

    In manufacturing IT/OT and MES/ERP contexts, PII may be stored or processed in systems such as HR platforms, badge access systems, incident logs, maintenance management tools, and plant-level applications that track operator actions or approvals.

    What PII usually excludes

    Information is typically not considered PII when it:

    • Has been de-identified or anonymized so that individuals cannot reasonably be re-identified
    • Is purely technical or equipment data with no link to a specific person (for example, machine cycle times or generic work order numbers)
    • Relates to business entities (such as company names or facility identifiers) without reference to a natural person

    Operational meaning in regulated environments

    In regulated manufacturing environments, PII handling is typically addressed through privacy and security policies, access controls, and data governance. Key operational considerations include:

    • Identifying which systems and data flows contain PII, such as HR integrations with MES, training records linked to operator qualifications, or supplier contact data in ERP
    • Limiting PII collection and retention to what is necessary for workforce management, safety, compliance, and operational use
    • Controlling who can view or modify PII within quality, maintenance, and engineering workflows
    • Logging and monitoring access to PII where required by internal policies or applicable privacy regulations

    Relationship to NIST SP 800-53 PT controls

    In the context of NIST SP 800-53, the PT (Personally Identifiable Information Processing and Transparency) control family is focused on how organizations process, protect, and provide transparency about PII. For industrial operations this typically means:

    • Understanding when manufacturing, HR, supplier, or engineering systems handle PII
    • Defining how PII is collected, used, shared, and minimized across IT and OT systems
    • Documenting notices and internal procedures related to PII while aligning with broader security controls

    Common confusion

    PII is sometimes confused with:

    • PHI (Protected Health Information): PHI is a specific category of health-related information associated with an individual in certain regulated contexts. PII is broader and not limited to health data.
    • Personal data (privacy regulations): Many privacy laws refer to “personal data” or similar terms. These concepts overlap heavily with PII but may be defined differently in specific legal frameworks.

    In manufacturing settings, another source of confusion is technical log data that contains user IDs or operator names. When such data can be linked to an identified or identifiable person, it is generally treated as PII for governance and control purposes.

  • Visualization layer

    The visualization layer is the part of an industrial or enterprise software stack that transforms raw or processed data into graphical views that humans can easily interpret. It typically sits on top of data sources such as MES, ERP, historians, OT systems, or data warehouses and focuses on presentation rather than storage or complex computation.

    In manufacturing and regulated environments, the visualization layer commonly includes dashboards, reports, real-time status boards, and analytic views that display information such as production status, work-in-progress, OEE, nonconformance trends, maintenance status, quality metrics, and supply chain indicators. It may be implemented through dedicated visualization tools, embedded reporting modules in MES/ERP, SCADA HMIs, or browser-based operations intelligence platforms.

    Key characteristics

    • Presentation-focused: Converts underlying data and KPIs into charts, graphs, alerts, and interactive screens, rather than performing primary control or heavy data processing.
    • Data-source agnostic: Can pull from multiple systems such as MES, ERP, QMS, LIMS, PLM, historians, and IoT platforms, often through APIs or data integration layers.
    • Role-specific views: Supports different perspectives for operators, supervisors, quality engineers, planners, and leadership, often via configurable dashboards and permissions.
    • Near real-time updates: In OT and MES contexts, often refreshes frequently so users can monitor equipment state, line performance, alarms, and exceptions.
    • Limited write-back: Some visualization layers are read-only; others allow limited interactions such as acknowledging alarms, adding comments, or triggering workflows in underlying systems.

    Operational context in manufacturing

    • On the shop floor: Andon boards, line status displays, and station-level HMIs that visualize machine state, takt time adherence, defect counts, or work instructions.
    • In quality and compliance: Dashboards for nonconformance rates, CAPA cycle times, audit findings, and inspection results, often sourced from MES, QMS, or SPC systems.
    • In planning and supply chain: Views of material availability, work order progress, shortages, and supplier on-time performance, typically fed by ERP and MES.
    • In performance management: KPI boards tracking OEE, downtime categories, throughput, and scrap, used in daily standups and continuous improvement reviews.

    Relationship to other layers

    The visualization layer is often distinguished from:

    • Data acquisition and control layers: PLCs, DCS, and low-level SCADA functions that directly interact with equipment and signals.
    • Application logic layers: MES, QMS, ERP, or workflow engines that implement business rules, sequencing, and approvals.
    • Data storage and integration layers: Databases, historians, data lakes, and integration middleware that store and move data between systems.

    In many architectures, the visualization layer consumes curated, contextualized data from these layers rather than connecting to all raw sources directly.

    Common confusion

    • Visualization layer vs. MES/QMS: An MES or QMS may include dashboards, but the system itself is not only a visualization layer. The visualization layer is specifically the presentation component, which may sit inside or outside those systems.
    • Visualization layer vs. HMI: HMIs are operator interfaces tightly coupled to specific machines or lines. A broader visualization layer often aggregates data from many assets and systems and serves multiple roles beyond local machine control.
    • Visualization layer vs. data warehouse or historian: Data warehouses and historians store and organize data; the visualization layer reads from them and renders it for human use.

    Use in regulated environments

    In regulated operations, the visualization layer is often used to monitor quality indicators, traceability coverage, backlog of reviews or approvals, and audit-relevant metrics. While it may surface compliance-related information and evidence, formal records and audit trails usually reside in underlying transactional systems and their databases, not in the visualization layer itself.

  • IT network

    An IT network is the interconnected set of communication infrastructure, devices, and services that support information technology systems for business and enterprise functions. In industrial and regulated environments, the IT network typically handles corporate applications, email, file services, ERP, MES front-ends, collaboration tools, remote access, and internet connectivity.

    The IT network usually includes switches, routers, firewalls, wireless access points, servers, storage, endpoint devices, and network services such as DNS, DHCP, directory services, and VPNs. It is generally managed by corporate IT or enterprise IT teams and is designed around confidentiality, integrity, and availability of business data, user productivity, and secure external connectivity.

    An IT network is distinct from operational technology (OT) networks, which focus on real-time control of physical processes and equipment such as PLCs, DCS, SCADA, and field devices. While IT and OT networks may exchange data (for example, for production reporting, quality systems, or maintenance planning), they are commonly segmented using firewalls or demilitarized zones (DMZs) to limit cybersecurity risk and to enforce clear ownership and change control.

    Common characteristics in manufacturing environments

    In manufacturing and other regulated operations, an IT network commonly:

    • Hosts enterprise applications such as ERP, LIMS, QMS, PLM, and corporate MES components
    • Provides user access to business systems, email, collaboration platforms, and document repositories
    • Connects to the internet and partner networks, usually through perimeter firewalls and security gateways
    • Implements centralized identity and access management, patching, endpoint protection, and monitoring
    • Interfaces with OT networks via tightly controlled links, gateways, or a DMZ for data exchange

    What an IT network typically does not include

    • Direct control of field devices, PLCs, or safety instrumented systems
    • Real-time control networks such as control buses, I/O networks, or vendor-specific industrial control backbones
    • Low-level deterministic control traffic where latency and jitter are tightly bounded

    Common confusion

    IT network vs OT network: An OT network focuses on monitoring and controlling physical processes (for example, production lines, utilities, environmental systems) and often has different availability and change-management requirements. An IT network focuses on business information systems and user services. In modern plants, the two domains are interconnected but are usually separated logically and physically for cybersecurity and operational reasons.

    IT network vs DMZ: A DMZ between IT and OT is not itself the IT network. It is a separate security zone used to mediate and control traffic between the IT network and the OT network, often hosting data brokers, jump hosts, or replication services.

    Relation to DMZ design between IT and OT

    When designing a DMZ between IT and OT networks, the IT network is the enterprise side of the boundary. It typically initiates or receives business-level data flows such as production reports, batch records, equipment status summaries, or maintenance information. The DMZ is used to separate the IT network from the OT network, ensuring that internet-facing or broadly connected IT systems are not directly exposed to control systems and plant-floor devices.

  • Conduit

    In industrial and manufacturing environments, a conduit most commonly refers to a physical protective pathway used to route and shield electrical power wiring, instrumentation lines, or data cabling. Conduits are used to protect conductors from mechanical damage, moisture, chemicals, and interference, and to organize wiring in a way that supports maintenance and safety requirements.

    Physical electrical and data conduit

    In plants and factories, conduit usually means a physical enclosure for cables, such as:

    • Metallic conduit (e.g., EMT, rigid, or flexible metal conduit) carrying power and control wiring to machines, panels, and sensors.
    • Non-metallic conduit (e.g., PVC) used where corrosion resistance or specific environmental protection is needed.
    • Cable trays, raceways, or dedicated conduits for Ethernet, fieldbus, and other OT/IT network cabling.

    Conduit is selected and installed based on factors such as voltage level, environment (wet, hazardous, cleanroom), mechanical stress, and applicable electrical and safety codes. In regulated manufacturing, conduit layouts for control systems, MES-connected equipment, and quality-critical instrumentation are typically documented and controlled to support maintenance, validation, and audits.

    Broader “conduit” usage in systems

    In a more abstract sense, conduit can also refer to a structured channel or mechanism through which information, materials, or transactions pass. For example:

    • A middleware service or integration layer acting as a conduit between MES and ERP systems.
    • A dedicated API gateway functioning as a conduit for production data between shop-floor equipment and analytics platforms.

    In these cases, conduit does not refer to a physical pipe but to a controlled pathway that connects systems or processes while enforcing specific rules or controls.

    What conduit is not

    Conduit is not the cable or data itself, and it is not the end device (such as a sensor, PLC, or server). It is the pathway or channel that connects and protects those elements. In physical installations, the conduit also does not typically include the junction boxes, enclosures, or terminal blocks, although these may be part of the same wiring system.

    Common confusion

    • Conduit vs. cable tray or raceway: In some facilities, these terms are used interchangeably. Strictly, a conduit is an enclosed pathway (pipe-like), whereas cable trays and raceways may be open or partially covered structures. Many standards and codes distinguish between them.
    • Conduit vs. channel or bus: In IT/OT and networking, a bus, channel, or link often refers to the communication method or protocol. A conduit, in contrast, is the physical or logical path along which that communication is carried.

    Operational relevance in regulated manufacturing

    In regulated or safety-critical manufacturing, conduit planning and documentation can affect:

    • Segregation of power, control, and data lines (for noise reduction and safety).
    • Separation of validated systems wiring from non-validated or test lines.
    • Cyber-physical security, when physical access to network conduits must be controlled.
    • Change control, where modifications to conduits that carry critical signals may require assessment, approval, and update of drawings and records.

    Conduit therefore plays both a practical and documentation role in how OT, IT, and facility services are implemented and managed over the life of a manufacturing system.

  • assessment and authorization (A&A)

    Assessment and authorization (A&A) is a formal, documented process used to evaluate the security and privacy controls of an information system and decide whether that system is approved to operate. It is widely used in government and regulated environments, and is often aligned with frameworks such as NIST SP 800-53.

    What assessment and authorization includes

    In most programs, A&A encompasses:

    • Assessment: Planning and performing an evidence-based review of implemented controls (technical, physical, and administrative) to determine whether they are correctly implemented, operating as intended, and producing the desired security and privacy outcomes.
    • Authorization: A risk-based decision by an authorizing official (or designated authority) to approve, conditionally approve, or reject system operation based on the assessment results and documented residual risks.

    The output typically includes an assessment report, a risk or security posture summary, and an authorization decision with defined terms, conditions, and review cycles.

    Use in industrial and manufacturing environments

    In industrial and manufacturing contexts, A&A is applied to information systems and operational technology (OT) that handle production data, quality records, configuration data, or regulated product information. Examples include:

    • Manufacturing execution systems (MES) and plant historians that store batch, genealogy, or traceability data.
    • Industrial control systems and SCADA platforms that interface with regulated production lines.
    • Integrated OT/IT environments where plant systems connect to enterprise ERP, quality, or supplier portals handling controlled technical data.

    For organizations working with U.S. federal agencies or handling controlled unclassified information, A&A activities are often aligned with programs such as FISMA, FedRAMP, or CMMC, which reference NIST SP 800-53 control baselines.

    Operational characteristics

    Practically, an A&A process commonly includes:

    • System categorization and definition of system boundaries.
    • Selection and tailoring of applicable security and privacy controls.
    • Implementation of controls and collection of objective evidence.
    • Independent or designated assessment of control effectiveness.
    • Documentation of findings, risks, and remediation plans.
    • Formal authorization decision with periodic re-assessment or continuous monitoring.

    In manufacturing operations, evidence may include configuration records, change control logs, access management records, network diagrams, backup and recovery test results, and monitoring or incident records relevant to production systems.

    Common confusion

    A&A vs. certification: A&A is a process and decision framework used within broader regulatory or contractual programs. It is not itself a certification and does not guarantee compliance to a particular standard. Instead, it uses control catalogs (such as NIST SP 800-53) as inputs to a documented risk decision.

    A&A vs. routine audits: Routine internal audits or inspections may feed evidence into an A&A, but A&A culminates in a formal authorization decision about whether a system is allowed to operate under defined conditions.

  • KPI store

    A KPI store is a centralized data layer, database, or service that is dedicated to calculating, storing, and serving key performance indicators (KPIs) in a consistent way across an organization. In industrial and manufacturing environments, it is commonly implemented as part of an operations intelligence, MES, or data platform architecture.

    Core characteristics

    A KPI store typically includes:

    • Standardized KPI definitions with agreed formulas, time bases, and filters (for example, a single definition of OEE, NPT, or yield).
    • Pre-calculated metrics at common grains such as shift, line, work center, asset, product, or work order.
    • Historical retention of KPI values for trend analysis, benchmarking, and audit support.
    • Programmatic access through APIs, queries, or analytic tools so that dashboards, reports, and MES or ERP screens all pull from the same values.
    • Data lineage and traceability that connect KPIs back to underlying event, production, quality, or transactional data.

    The KPI store may be implemented in a data warehouse, data lakehouse, time-series database, or as KPI-focused tables within an MES or historian, as long as it acts as the designated source of truth for KPI values.

    Operational usage in manufacturing

    In regulated or complex manufacturing, a KPI store commonly supports:

    • Shop-floor visibility by feeding consistent KPIs to operator boards, andon systems, and daily management reviews.
    • Management reporting on OEE, throughput, scrap, rework, schedule adherence, and other operational metrics across plants or value streams.
    • Quality and compliance monitoring through standardized defect, NCR, CAPA, and COPQ-related indicators.
    • Cross-system alignment so that MES, ERP, QMS, and BI tools all use the same KPI values and definitions, reducing reconciliation effort.

    What it is not

    A KPI store is not:

    • Raw data storage only. It is more than a simple data lake or historian; it focuses on curated, computed indicators.
    • Just a dashboard tool. Visualization tools may consume data from the KPI store but do not replace the store itself.
    • A full MES or ERP. Those systems generate events and transactional data; the KPI store organizes and standardizes metrics derived from that data.

    Common confusion

    • KPI store vs data warehouse: A data warehouse holds broad subject-area data, whereas a KPI store is scoped to standardized metrics (sometimes implemented as a layer inside the warehouse).
    • KPI store vs historian: A historian captures high-frequency time-series data from equipment; a KPI store typically uses aggregated or processed data, often including non-OT sources such as ERP and QMS.