Automation Object Binding for Flexible Industrial Controller Selection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In industrial automation, existing systems require significant rewrites of controller logic and visualization code whenever hardware modifications are made, such as introducing new controllers or changing hardware components, leading to inefficiencies and increased processing costs.
Innovation Solution
The implementation of late binding of automation objects to controller logic and load balancing across industrial controller resources, allowing for the creation of base code with generic placeholders that can be replaced with specific objects and executed on selected controllers based on requirements, reducing the need for extensive code rewriting.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If controller logic and visualization code are written with specific hardware specifications known in advance, then the code can be optimized for that hardware, but significant rewrites are required when hardware modifications are made
Solution Approach 1:
The system segments controller logic into discrete automation objects that can be independently selected and bound to controllers. Each automation object represents a specific hardware component or control function, allowing individual objects to be modified or replaced without rewriting entire codebases. This segmentation enables granular control and simplifies maintenance when hardware changes occur.
Solution Approach 2:
The patent implements a universal automation object model that can represent multiple types of hardware components and control logic in a standardized format. These automation objects serve multiple purposes: they define control logic, specify hardware requirements, and enable runtime controller selection. This universality allows the same object library to support various hardware configurations without requiring dedicated code for each scenario.
2Productivity
If new controllers are introduced to the automation system, then processing capacity increases, but developers must re-write large portions of code to accommodate new resources
Solution Approach 1:
The system implements dynamic controller selection and binding, where automation objects are not statically assigned to specific controllers at compile time. Instead, controllers are selected at runtime based on the automation objects' requirements and available resources. This dynamic approach allows the system to adapt to new controllers without code changes, as the binding process automatically matches objects with suitable controllers based on their specifications.
Solution Approach 2:
The automation object model enables self-service functionality where objects automatically specify their own controller requirements and selection criteria. Each automation object contains information about its hardware requirements, scan rate needs, and controller capabilities, allowing the system to autonomously match objects with appropriate controllers without developer intervention. This self-describing approach simplifies integration of new controllers into the system.
3Reliability
If code is written with specific hardware specifications, then execution can be optimized for that hardware, but flexibility to adapt to different hardware configurations is reduced
Solution Approach 1:
The system uses parameter-based automation objects that define controller requirements through configurable parameters such as scan rate, I/O specifications, and processing capabilities. Rather than hardcoding hardware-specific logic, the objects specify their requirements in terms of parameters that can be matched against available controllers. This parameter-driven approach maintains execution efficiency by ensuring objects run on controllers that meet their specifications while allowing flexibility to adapt to different hardware configurations.
4Manufacturing precision
If developers write code knowing exact hardware specifications, then the code can be precisely tailored to hardware capabilities, but the system becomes difficult to modify when hardware changes
Solution Approach 1:
The automation object serves as an intermediary layer between the control logic and the physical hardware. Rather than writing code that directly references specific hardware components, developers create automation objects that abstract hardware interactions. These objects mediate between the control logic and actual hardware, allowing precise control specifications while decoupling the logic from hardware details. This intermediary approach enables easy hardware modification by simply replacing or reconfiguring automation objects rather than rewriting control logic.
Data Source
AI summary
The present disclosure is directed to systems, methods and devices for facilitating object-based industrial automation control. An automation control library comprised of a plurality of objects may be maintained in association with one or more industrial automation applications. Code defining the execution of an industrial automation process may be received. A plurality of objects in the object library for implementing the industrial automation control process may be identified. The plurality of identified objects may be matched to one or more hardware components based on one or more operational requirements included in the code, and available hardware resources for performing the automation control process.