1. Definition of Control Product Integration

Control Product Integration is the domain that integrates the control system with the functions, mechanisms, electrical systems, safety systems, operation methods, manufacturing processes, commissioning activities, and maintenance structure of a machine product so that control operates consistently as an integral part of the complete product.

A control system is not completed simply by providing the following elements:

• PLC program

• Sensors and output devices

• Servo drives and inverters

• HMI

• Electrical control panel

• Communication network

These elements must be connected to the actual product structure and lifecycle.

• Product requirements must be linked to control functions.

• Mechanical directions of motion must match control commands.

• Sensor positions must correspond to state-decision criteria.

• Electrical drawings must correspond to program I/O.

• Hardware and software configurations must be derived according to product specifications.

• The same functions must be reproduced across all manufactured machines.

• Fault diagnosis and component replacement must be possible at the customer site.

• Modified programs and parameters must be traceable for each machine.

The essence of Control Product Integration is therefore as follows:

Control is not added to the machine as a separate system. It is incorporated into the structure and lifecycle of the machine product.

2. Scope of the Term Product

In Control Product Integration, the term Product does not mean the workpiece or item processed by the machine.

It refers to the machine or equipment delivered to the customer.

Examples:

• Automatic assembly machine

• Packaging machine

• Inspection machine

• Transfer equipment

• Processing equipment

• Food-processing machinery

• Production-line module

• Robot cell

• Custom automation equipment

A machine product generally consists of the following areas:

Control Product Integration organizes and manages the relationships among these product areas.

3. Position within the Control System

The development flow of a machine product can be expressed as follows:

Product Requirements → Product Architecture → Mechanical/Electrical Design → Control Design → Control Implementation → Product Integration → Verification → Manufacturing Release

The role of each stage is as follows:

Control Implementation focuses on implementing the control system itself.

Control Product Integration ensures that the implemented control system operates correctly within the complete machine product.

4. Difference from Control Implementation

Control Implementation

Primarily addresses:

• PLC and controller selection

• I/O configuration

• Program structure

• Motion implementation

• Communication implementation

• HMI implementation

• Electrical implementation

• Functional testing

Control Product Integration

Primarily addresses:

• Linking product requirements to control functions

• Defining boundaries between machine modules and control modules

• Managing mechanical, electrical, and software interfaces

• Defining control configurations for each product specification

• Ensuring manufacturing and assembly repeatability

• Supporting service and component replacement

• Managing product changes and software versions

• Supporting the product throughout its lifecycle after delivery

Control Implementation addresses how control is implemented.

Control Product Integration addresses how that control operates consistently throughout the complete product.

5. Fundamental Integration Areas

Control Product Integration includes four primary forms of integration.

5.1 Functional Integration

Connects required product functions to control functions.

Examples:

• Connecting a metered-feeding function to motors, sensors, and weighing logic

• Connecting a product-clamping function to clamps, pressure monitoring, and position confirmation

• Connecting an inspection function to cameras, decision logic, and reject handling

5.2 Physical Integration

Ensures that control devices are properly installed within the physical machine structure.

Examples:

• Sensor location

• Motor and drive placement

• Control-panel installation

• Operator-panel position

• Cable and piping routes

• Safety-device location

5.3 Information Integration

Connects data and state information used within the product.

Examples:

• Product number

• Recipe

• Process state

• Inspection result

• Alarm

• Machine parameter

• Maintenance information

5.4 Lifecycle Integration

Considers assembly, manufacturing, commissioning, service, modification, and disposal after the design stage.

6. Linking Product Requirements to Control Functions

Control functions must be traceable to product requirements.

Example:

Each requirement should be linked to:

• Related function

• Related device

• Related software module

• Configuration parameter

• Test method

• Acceptance criterion

Without a defined link between requirements and implementation, a program may exist, but the required product performance cannot be clearly demonstrated.

7. Alignment of Product and Control Architectures

The physical modules of the machine and the control-software modules should correspond wherever possible.

Example:

This structure simplifies:

• Function-specific testing

• Module replacement

• Product-variant development

• Software reuse

• Fault isolation

• Maintenance

• Production-line expansion

If the mechanical architecture and software architecture are unrelated, changing one machine module may affect multiple software areas in an irregular and difficult-to-manage manner.

8. Definition of Product-Module Boundaries

Each product module should have clearly defined boundaries.

Physical Boundary

• Frame and mounting surfaces

• Product inlet and outlet

• Power connection

• Pneumatic and hydraulic connection

• Cable connection

Functional Boundary

• Function performed

• Start condition

• Completion condition

• Abnormal condition

• Recovery condition

Control Boundary

• Input signals

• Output signals

• State information

• Command information

• Interlocks

• Communication data

Responsibility Boundary

• Functions handled within the module

• Functions handled by the higher-level controller

• Functions requiring coordination with other modules

Clear module boundaries allow independent testing and module reuse.

9. Interface Management

In product integration, more problems occur at interfaces between systems than within the individual devices themselves.

Major interfaces include:

• Mechanical–Control Interface

• Electrical–Control Interface

• Pneumatic–Control Interface

• Software–Software Interface

• Machine–Operator Interface

• Machine–Line Interface

• Machine–Manufacturing Interface

• Machine–Service Interface

The following should be defined for each interface:

• Input and output

• Data direction

• Signal meaning

• Normal state

• Failure state

• Timing condition

• Responsible party

• Test method

10. Mechanical–Control Interface

Mechanical design information must be consistent with control logic.

Required Information

• Reference axis direction

• Motor forward and reverse directions

• Cylinder forward and reverse directions

• Home and operating positions

• Mechanical limit positions

• Travel distance

• Speed and acceleration limits

• Load and inertia

• Backlash

• Settling time

• Collision zones

• Positions that must be maintained

Main Integration Checks

• Does the positive control direction match the actual direction of movement?

• Do software limits correspond to mechanical limits?

• Does the sensor position represent the actual completion state?

• Is the brake-release sequence coordinated with the axis-drive sequence?

• In which direction does the device move during power loss?

• Is the mechanical tolerance smaller than the state-decision tolerance?

11. Electrical–Control Interface

Electrical drawings, I/O lists, program variables, and actual wiring must remain consistent.

Connection Relationship

Field Device → Terminal Block → I/O Module → I/O Address → Program Variable → HMI Display

Example:

Clamp Forward Sensor

• Device ID: LS-CL01

• Terminal number: TB2-14

• PLC input: X120

• Variable name: DI_CLAMP_FWD

• HMI state: Clamp Forward

• Related function: Clamp Function

• Test item: Clamp I/O Check

This relationship must be maintained so that field faults can be traced efficiently.

12. Pneumatic/Hydraulic–Control Interface

Pneumatic and hydraulic systems should not be defined only in terms of valve ON and OFF states.

Information to Integrate

• Normal valve state

• Valve state during power loss

• Natural direction of cylinder movement

• Pressure-retention behavior

• Residual pressure

• Exhaust method

• Speed regulation

• Pressure monitoring

• Drop prevention

• Behavior during repressurization

Connection to Control

• Normal-pressure condition

• Operation-start permission

• Completion sensor

• Timeout

• Protective action during pressure loss

• Recovery condition after repressurization

13. Integration of Software Interfaces

A machine product may contain several control-software systems.

Examples:

• PLC program

• Safety PLC program

• HMI project

• Servo parameters

• Inverter parameters

• Robot program

• Vision program

• Industrial-PC software

The interfaces among these software systems must be defined.

Main Information

• Command

• State

• Completion

• Error

• Recipe

• Product information

• Time information

• Synchronization signal

• Data validity

• Version information

It is not sufficient for the software systems merely to be connected.

The system must identify which product, which cycle, and which point in time the data belongs to.

14. Integration of HMI and Product Operation

The HMI is not simply a screen for displaying controller variables.

It is the interface through which the operating method of the product is implemented.

Items to Connect to Product Operation

• Machine start

• Machine stop

• Model change

• Recipe selection

• Manual operation

• Homing

• Fault recovery

• Maintenance

• Production-information review

HMI Integration Principles

• The screen structure should reflect the actual machine structure.

• Device names on the screen should match field labels.

• Only operations permitted in the current mode should be displayed or enabled.

• The reason for prohibited operation should be shown.

• Recovery procedures should be provided step by step.

• The units and effects of settings should be displayed.

• Functions not included in a product configuration should be hidden or disabled.

15. Product Integration of Safety Functions

Safety functions should not be treated as separate components added to the product.

They must be integrated into the product structure and operating method.

Integration Targets

• Safety doors and machine frame

• Door switches and safety controller

• Safety outputs and drives

• Brake and vertical axis

• Safe speed and setup operation

• Restart prevention and operating procedure

• Emergency stop and energy isolation

Items to Review

• Is the physical position of the safety device appropriate?

• Is the hazardous motion actually removed?

• What happens to the product and tooling after a safety stop?

• Is a safe operating method available for maintenance work?

• Can a standard PLC failure interfere with the safety function?

• Is the safety-program version managed for each product?

16. Product Specifications and Control Configuration

Even machines based on the same platform may have different specifications according to customer requirements.

Examples:

• Different number of axes

• Additional sensors

• Additional inspection functions

• Different product sizes

• Different operating speeds

• Different communication standards

• Different safety standards

• Different HMI languages

Rewriting the entire program for each specification is difficult to manage.

Product specifications should preferably be managed using the following structure:

• Base Configuration

• Optional Module

• Regional Configuration

• Customer Configuration

• Software Feature Option

• Parameter Set

17. Common Platform and Option Structure

For a product family, a common control platform can be defined.

Common Areas

• Base PLC

• Standard I/O structure

• Standard operating modes

• Common alarm structure

• Common HMI screens

• Standard communication

• Base safety architecture

• Common software library

Optional Areas

• Additional motion axes

• Vision inspection

• Robot

• Automatic feeding

• Remote service

• Production-management integration

• Additional safety functions

Options should be managed as complete configuration units that include hardware, software, documentation, and test conditions, rather than simply being hidden behind software bits.

18. Product Configuration Management

The control configuration of each product must be clearly identifiable.

Items to Manage

• Machine model

• Serial number

• PLC model

• I/O module configuration

• Motion-axis configuration

• Safety configuration

• Communication options

• Program version

• HMI version

• Parameter set

• Option list

Managing the configuration of each machine as a single Configuration Record improves field support and component replacement.

19. Connection Between BOM and Control Configuration

The product BOM should include control components.

Examples of Control BOM Items

• PLC CPU

• I/O modules

• Servo drives

• Inverters

• Safety controller

• HMI

• Network switch

• Sensors

• Valves

• Relays

• Power supplies

• Cables

• Connectors

The hardware BOM and software configuration must be connected.

Example:

20. Parameter and Recipe Integration

Product-specific settings and machine-specific settings must be separated.

Machine Parameter

Defines characteristics specific to the machine.

Examples:

• Home offset

• Machine travel limit

• Motor direction

• Sensor calibration value

• Standard pressure

• Safety limit value

Product Recipe

Defines values that change according to the item being processed or manufactured.

Examples:

• Product position

• Processing time

• Target temperature

• Feed quantity

• Inspection criteria

• Clamping force

If Machine Parameters and Product Recipes are mixed, machine-specific settings may be changed incorrectly during a model change.

21. Integration of Product Information and Control Data

The control system must keep the physical product synchronized with its product data.

Examples of Product Information

• Product ID

• Model

• Batch number

• Process number

• Recipe

• Inspection result

• Pass/fail status

• Rework status

Integration Principles

• Product data should move together with the physical product.

• Related data should be cleared when the product is removed.

• Duplicate products and duplicate data should be detected.

• A data-resynchronization method should exist after communication failure.

• A data-entry method should exist for manually loaded products.

22. Integration with Assembly

Control design must be implementable during the assembly process.

Documentation Required during Assembly

• Sensor installation drawing

• Cable-routing drawing

• Control-panel layout

• Terminal-block drawing

• Motor direction

• Valve direction

• Connector list

• Labeling rules

• Adjustment criteria

• I/O check sheet

Core Principles of Assembly Integration

• Make incorrect component installation difficult.

• Prevent incorrect connector insertion.

• Provide sufficient sensor-adjustment range.

• Use replaceable cable structures.

• Allow independent functional checks after field assembly.

23. Integration with Manufacturing

A productized control system must support repeatable manufacturing.

Manufacturing Standardization Targets

• Control-panel structure

• Component arrangement

• Cable length

• Wire numbering

• I/O addresses

• Program download

• Parameter entry

• Network configuration

• Functional testing

• Final backup

Methods for Reducing Manufacturing Variation

• Use standard programs.

• Apply automatic parameter loading.

• Use product-specific configuration files.

• Link configuration to barcode or serial number.

• Use automated I/O checking.

• Apply standard test procedures.

• Record manufacturing history.

24. Integration with Commissioning

Commissioning is not merely a stage for adjusting software.

The following must be verified together:

• Mechanical and control directions

• Electrical wiring

• Sensor positions

• Motor and cylinder operation

• Interlocks

• Protective functions

• Safety functions

• Product recipes

• Cycle time

• Quality criteria

Commissioning Stages

1. Verify power supply and grounding.

2. Perform I/O Check.

3. Verify device directions.

4. Test individual functions.

5. Test connections between functions.

6. Test abnormalities and protective functions.

7. Test safety functions.

8. Test with actual products.

9. Test performance and cycle time.

10. Store final settings.

25. Product Verification and Acceptance Criteria

The integrated control system must be verified against the product requirements.

Verification Areas

• Function

• Performance

• Accuracy

• Productivity

• Quality

• Abnormal response

• Safety

• Operability

• Maintainability

• Data traceability

Examples of Acceptance Criteria

• Positioning accuracy

• Cycle time

• Production quantity

• Alarm-detection time

• Stopping time

• Recovery time

• Product-change time

• Communication-recovery time

• Stability during repeated operation

26. Integration with Service and Maintenance

Fault diagnosis and control-component replacement must be possible at the customer site.

Required Functions

• Device-specific diagnostic screens

• I/O monitor

• Interlock-status display

• Alarm causes and corrective actions

• Parameter backup

• Replacement procedures

• Program restoration

• Remote diagnosis

• Maintenance history

Process Required after Replacement

1. Confirm the replacement component.

2. Confirm the part number.

3. Apply the required program or parameters.

4. Verify communication.

5. Verify I/O.

6. Confirm direction and operating range.

7. Perform limited testing.

8. Approve automatic operation.

27. Change Management

When the mechanical, electrical, or software design changes, the effect on other product areas must be reviewed.

Examples:

• Cylinder-size change

• Motor change

• Sensor change

• PLC change

• Communication-standard change

• Program-logic change

• Safety-device change

Change-Impact Review

• Functional requirements

• I/O

• Electrical drawings

• Software

• HMI

• Safety logic

• Parameters

• Parts list

• Test procedures

• Manuals

• Previously delivered equipment

A change should not be managed by modifying only the program file.

28. Version and Configuration Management

The following versions should be linked for each product:

• Mechanical-drawing version

• Electrical-drawing version

• PLC-program version

• HMI version

• Safety-program version

• Servo-parameter version

• Recipe version

• Network-configuration version

• Test-specification version

This information should be linked to the machine serial number.

29. Integration of Suppliers and External Devices

External systems such as robots, vision systems, inspection units, and feeders may use different control methods depending on the supplier.

Information Required from Suppliers

• I/O list

• Communication protocol

• Command and state definitions

• Alarm list

• Recovery method

• Default parameters

• Program backup

• Software version

• Test results

• Safety interface

The meaning of signals such as Ready, Busy, Complete, and Fault must be clearly defined for each external device.

30. Product Integration of Cybersecurity

When the control system is connected to a network, cybersecurity becomes part of the product functionality.

Main Items

• User authority

• Remote access

• Network segmentation

• Program-download authority

• Parameter-change authority

• Log recording

• Backup protection

• Update procedures

• External-storage-device management

Security settings should be defined as part of the product configuration rather than applied independently at each site.

31. Product Lifecycle and Control Support

The control system must be supported after product delivery.

Lifecycle Stages

• Design

• Assembly

• Manufacturing

• Commissioning

• Customer delivery

• Operation

• Maintenance

• Modification

• Software update

• Disposal

The required control information and responsibilities should be defined for each stage.

32. Major Design Deliverables

33. Review Questions for Control Product Integration

Product Requirements

• Are product requirements linked to control functions?

• Is a test method defined for each requirement?

• Do control functions reflect the actual purpose of the product?

Product Architecture

• Do machine modules correspond to control modules?

• Are module responsibilities and boundaries clear?

• Are the common platform and options separated?

Interfaces

• Are mechanical, electrical, pneumatic, and software interfaces defined?

• Is the owner of each command and state clear?

• Are normal and failure states defined?

• Are timing conditions and timeouts defined?

Product Specifications

• Is the hardware configuration defined for each model and option?

• Are software functions defined for each option?

• Are unavailable functions prevented from being enabled incorrectly?

• Are product-specific parameters managed?

Manufacturing

• Can the same product configuration be manufactured repeatedly?

• Can programs and parameters be applied automatically or through a standard procedure?

• Can functions be independently verified during manufacturing?

• Are the final configuration and version recorded?

Service

• Can fault causes be identified in the field?

• Can settings be restored after component replacement?

• Can the program version of each machine be confirmed?

• Can the effect of changes on installed machines be traced?

Verification

• Are function, performance, safety, and protective functions tested together?

• Is the test scope defined for each product specification?

• Are assembly and manufacturing variations considered?

• Has the product been verified under actual customer operating conditions?

34. Conclusion

Control Product Integration is the domain that connects the control system to the functions, structure, electrical system, safety system, operation method, manufacturing process, and service structure of the machine product.

Its essence is not simply installing a controller or downloading a program.

The following relationships must be configured consistently:

• Product requirements and control functions

• Machine modules and control modules

• Mechanical motion and control commands

• Sensor signals and actual states

• Electrical wiring and program variables

• Product options and control configurations

• Product data and the actual product

• Manufacturing processes and software application

• Delivered machines and software versions

• Maintenance and component replacement

• Product changes and verification scope

Proper Control Product Integration prevents the control system from existing as an independent accessory.

It incorporates control into the complete lifecycle of the machine product, including design, assembly, manufacturing, commissioning, operation, and maintenance, so that product functions and performance can be reproduced consistently.

It also manages machine models, options, software, parameters, electrical drawings, test documentation, and service information as one product configuration, maintaining control consistency and traceability even when product specifications become more diverse or the equipment remains in operation for an extended period.